BEST AVAILABLE COPY 



UK Patent Application „9,GB „«2354611 , 3, A 



(43) Date of A Publication 28.03^1 



(21) 


Application No 0013072.4 


(51) 


INT CL^ 






GOAF 17/30 9/44 


IZZJ 


USIB Of riling J i.ln>.^UUv 


(52) 


UK CL (Edition S ) 


font 


Priority Data 

<31) 09333058 (32) 14.06.1999 (33) US 




G4A APX AUDB 




(31) 09332818 (32) 14.06.1999 


(56) 


Documents Cited 

GB 2312766 A WO 89/02631 A 








**The NIC Name Server...", Jul 79, at 


1/1/ 


MppncanTiSf 

International Business Machines Corporation 




http://commijnity.roxen.com/developers/idocs/ 
rfc/Hc756.html "KNS • Ken's Name Server", 6 Nov 98, 




(Incorporated in USA - New York) 




at http://staff.washington.edu/krl/proiects/kns.html 

Field of Search 




Armonk, New York 10504, United States of America 


(58) 


(72) 


Inventor(s) 
Jeffrey A Frey 
David A Booz 
Timothy J Hahn 
Theodore R Maeurer 




UK CL (Edition S ) G4A APX AUDB 
INT CL^ G06F 9/44 9/46 17/30 

Online: Ef»ODOC, INSPEC, Internet JAPIO, TDB, WPI, 
XPESP 



Carroll E Fulkerson Jr 

Rodney A Little (74) Agent and/or Address for Service 

GarySPuchkoff CBoyce 

Christopher P Vignola IBM United Kingdom Limited, Intellectual Property 

Dept Hursley Park« WINCHESTER, Hampshire^ 
S021 2JN, United Kingdom 



(54) Abstract Title 

A transactional name service 

(57) One or more objects 1602 of a name server 1606 are managed as transactional objects, thereby 
providing a transactional name server. Atonnic updates are provided in the name server by the addition of 
transactional semantics. The transactional semantics include making the objects of the name space managed 
objects and providing a local interface to a directory service that propagates a transactional context from the 
name server through a directory down to a resource manager. Binding and naming context classes support 
the same attributes, hence act as dual personalities for the same underlying directory data, allowing efficient 
one-hop lookup of objects that reside in a particular name server. 



SYSTEM NAME SPACE 



1600 



HMiE SERVER 
SYSTEM 1 



1606^ 



NAME SERVER 
SYSTEM 2 




fig. 16a 



O 
CD 

CO 



1 /29 

SERVER SYSTEM 



OPERATING SYSTEM 



114 



120 



SERVER N 



SERVER 2 



SERVER 1 
CONTAINER^ 
118^ ^ 

^object) 

116 



OBJECT REQUEST 
BROKER 



138 




108 



RESOURCE 
MANAGER 



COMPONENT 
BROKER RUNTIME 
SERVICES 



102 



110 



CLENT SYSTEM 





\ OPERATING SYSTEM 


136 




OBJECT REQUEST BROKER " 


128 








/^REMOTE ACCESS>v 
V^PROXY OBJECT/ 


130 










(^^^LICATION^ 






CLIENT 





100 



112 




EXTERNAL 
STORAGE 



104 



2 /29 




200 



INTEROPERABLE OBJECT REFERENCE 



HEADER 


NETWORK ADDRESSING 


OBJECT 




INFORMATION 


KEY 





302 



304 



fig. 3 306 



SERVER 1 



120 



404 




OBJECT REQUEST 
BROKER 



CLASS 
MANAGER 



,406 



fig. ^ 



3/29 



C START ) 



REQUESTER PAS: 
REFERENCE T 
CONTAINER AND RE( 


5ES AN OBJECT 
0 THE ROOT 
3UESTS A POINTER 




r 


ROOT CONTAINER STRIPS 
OFF ITS PART OF THE KEY; 
PASSES REST TO NEXT CONTAINER 






CONTAINER STRIPS OFF ITS 
PART OF THE KEY 






CONTAINER BUILDS THE 
LOCAL PROXY 






CONTAINER RETURNS ADDRESS OF 
LOCAL PROXY BACK TO REQUESTER 



500 



502 



504 



506 



508 




4/29 



CSTARTJ 

1 600 

CONTAINER DETERMINES WHAT 
OBJECT IS REPRESENTED 
BY THE REFERENCE 



CONTAINER RETRIEVES AN 
ENTRY. FOR A LOCAL 

' PROXY FACTORY FOR 
THAT OBJECT TYPE 



I 



CONTAINER CREATES AN 
INSTANCE OF THE 
LOCAL PROXY 



602 



604 




(END) 



f'i'9- 6 



5/29 




6/29 



( START ) 



ACTIVATION 



CLIENT PACKAGES K^SOO 
UP A REQUEST 



I 



REMOTE ACCESS PROXY OBJECT PASSES ^802 
OBJECT KEY AND DATA TO SERVER 



SERVER ORB DRIVES KE'f J OOB J 804 
METHOD ON CONTAINER 



I 



CONTAINER STRIPS OFF 
APPLICABLE PART OF KEY 
AND DETERMINES IF CONTAINER 
ASSOCIATED WITH KEY IS ACTIVE 




■806 



810 



ACTIVATE CONTAINER 



814 



EXCEPTION 



BUILD A LOCAL ACCESS PROXY [^818 



I 



PASS POINTER TO LOCAL 
PROXY BACK TO CALLER 



(end) 



-^820 

fig. 8 A 



7/29 



C START ) 
1 



REQUESTER DRI VES METHOD 

\ 



822 



LOCAL PROXY OBTAINS ADDRESS 
OF OBJECT 



I 



^824 



CONTAINER SELECTS VIRTUAL MEMORY 
COPY OF THE OBJECT 



^^826 



LOCAL PROXY DELEGATES 
METHOD REQUEST 



T 



828 



OBJECT PERFORMS ITS BUSINESS .^830 
FUNCTION AND RETURNS 
TO LOCAL PROXY 



LOCAL PROXY CONSULTS 
WITH THE CONTAINER 



T 



LOCAL PROXY RETURNS 
TO THE REQUESTER 



T 




Jig. SB 



J- 



834 



8 /29 




120 



900 



OPERATING SYSTEM 



SERVER N 



OBJECT REQUEST BROKER 



OBJECT TRAN. SERVICE 




1U 



RESOURCE RECOVERY SERVICE 



902 

U 



9/29 



SERVER 



1006 



1000 



1002 



RESOURCE 
MANAGER 




fig. 10 



OPERATING SYSTEM 



SERVER 1 



CONTAINER 



1106 



1108 




CONNECTION 
OBJECT 




1114 



_^rRRSAF|— 
t I 



OBJECT REQUEST B ROKER 

I 



OBJECT TRAM SERVICE 



RESOURCE RECOVERY SERVICE 



1112 

h 



1110 





RESOURCE 


ATTACH 


MANAGER 




1 



r ifdNTYxTs" ^ 

1 . IRAN 

•SECURITY 
• •WLM 



1104 



1100 

1118 
1116 



10/29 



SERVE R 
CONTAINER 
1206 ^202 



1200 




BUSINESS 
OBJECT 




1208 



fig, 12a 



1210 



RESOURCE 
MANAGER 
1 



1204 



EXTERNAL 
STORAGE 



SERVER 




RESOURCE 
MANAGER 
1 



1222 



RESOURCE 
MANAGER 
N 



fig. 12b 



13 /29 



C START ) 



CLIENT RECEIVES AN INDIRECT 
OBJECT REFERENCE 






CLIENT ISSUES A LOCATE REQUEST 
USING INDIRECT OBJECT REFERENCE 


\ 




DAEMON CONSULT 
MANAGER TO C 


s with workload 

:hoose server 



7400 



1402 



1404 



1406 



DAEMON REPLIES TO LOCATE REQUEST 
WITH A LOCATION FORWARD REPLY 



1408 



CLIENT USES DIRECT REFERENCE 
TO GET TO CHOSEN SERVER 



(END| 

fig. 14 



i ; : 



U /29 
C START ^ 



SERVER RECEIVES METHOD REQUEST 
AND A DISTRIBUTED TRANSACTION CONTEXT 



1500 

1/ 




SERVER ATTEMPTS TO REGISTER THE 
SERVER'S INTEREST IN TRANSACTION 




SERVER OBTAINS 
REGISTRATION INFORMATION 



i 



NEW OBJECT 
REFERENCE IS BUILT 



I 



1512 
1514 



SERVER RETURNS A LOCATION 
FORWARDING REPLY TO CLIENT 



1516 



CLIENT ESTABLISHES CONNECTION LaJ 
WITH APPROPRIATE SERVER 



fig. 15 



^N0|— -t/ 



1508 



15/29 



SYSTEM NAME SPACE 



1600 



NAME SERVER NAME SERVER 

SYSTEM 1 .™ . SYSTEM 2 




fig. 16a 



NAME SPACE 



NAME SERVER 
SYSTEM 1 



1606 





I I 

16/29 




fig. 17 



17/29 

Cos:Noming:i4omingContext 



INTERFACE 



IExtende<flJomingr 
NomingContexl 



INTERFACE 



NaningServicerBinding 



INTERFACE 



IMonogedServerr 
IMonogedObjectWithOotoObject 



INTERFACE 




INTERFACE 



NcnungService: 
NonmngContextBO 



INTERFACE 

T 



NarntngService:£indingBO 



IMPL 



IMPL 



Nonnin^ServiceO(h 
NcvrangCOntextBO 



Nornin^ervicdX): 
NomingContextOO 



\ 




NanuigService:£in(f»ig30 



N(»T)ingServiceOO:£indingDO 
\ 



NaminglServiceOQilamingContexlOO^ 




LEGEND 
INHERITANCE 
DELEGATION 



NomingServiccOOu 
y^BindingOO 



fig. 18 



lUonogedServer: 
lOotoObjecl 



INTERFACE 



18 129 



NAME SPACE 



1902 



SYSTEM A 



SYSTEM B 



NAME 
SERVER 




NAME 
SERVER 


ROOT 
NAMING 
CONTEXT 






"B" 




1900 




( ^amingV 




/namingV 


VCONTEXy 




^ONTEXy- 



1908 



1906 



LDAP ^^1904 



DCE 
COS 



1910 



fig. 19 



19/29 



C START J 



2000 



CONSTRUCT PRIMARY KEY 




2002 

SEARCH FOR THE OBJECT \^ 
IDENTFIED BY PRIMARY KEY ^ 




2004 



2006 



2008 

SEARCH FOR A PORTI ON OF THE NAMe] 



RETURN 
OBJECT 



2010 



2012 




DISJUNCTIO N LOCATED: RETRIEVE OBJECt] 

1 



REDRIVE RESOLVE ON THE 
OBJECT USING REMAINDER OF NAME 



2016 



1 ' 

(END) 




fig. 20 



20 /29 



( START ^ 



2100 



METHOD REQUEST PLOWS FROM 
CLIENT TO NAME SERVER 



2102 



ORB EXTRACTS OBJECT KEY FROM 
lOR OF INBOUND REQUEST AND 
PASSES IT TO THE CONTAINER 



li 



2104 



CONTAINER CREATES NAMING CONTEXT 
DATA OBJECT AND PROVIDES 
THE OBJECT KEY 



1/ 



2106 



DATA OBJECT EXTRACTS THE CORBA 
NAME FiROM THE OBJECT KEY 



2108 



CORBA NAME REVERSED AND USED TO 
CONSTRUCT THE DISTINGUISHED NAME 



2110 



DATA OBJECT USES THE DISTINGUISHED 
NAME TO RETRIEVE THE DATA 



2112 



OBJECT INSTANTIATION COMPLETES 
AND METHOD IS DISPATCHED 



T 




(END) 



fig. 21 



21 /29 



C START } 







OBTAIN PRIMARY KEY OF CURRENTLY _ 
EXECUTING NAMING CONTEXT 


\ 


r 


1 CONVERT KEY TO A CORBA NAME [ 






1 APPEND INPUT NAME TO CORBA NAME 


] 


r . i 


CONVERT RESULTING CORBA J 
NAME TO PRIMARY KEY 



2202 



I 




END) 



fig. 22 



22 /29 




1— 




RESOURCE 
MANAGER 


OMPONEN 
BROKER 
RUNTIME 
SERVICES 











o 

CM 



J 



23/29 



C START ) 



TRANSACTION BEGINS 



2400 



2402 



1 DATA OBJECT IS CREATED h 






BUSINESS OBJECT IS CREATED AND 
ASSOCIATED WITH DATA OBJECT 


\ 


[ , 



2404 



2406 



2408 



NEW DIRECTORY ENTRY IS CREATED 



T 



fig. 24 



24/29 



C START ) 



2500 



CLIENT UPDATES BUSINESS 
OBJECT ATTRIBUTES 



ly 



2502 



TRANSACTION COMMITS 


) 




BUSINESS OBJECT ATTRIBUTES ARE . 
FLOWED TO DATA OBJECT 


\ 




ATTRIBUTES ARE STORED 
IN LDAP DIRECTORY 


\ 




LDAP STORES ATTRIBUTES IN DB2 



2504 



2506 



2508 



2510 



BUSINESS AND DATA OBJECTS ARE 
DELETED FROM MEMORY 




1 


DB2 RECEIVES A PREPARE 
AND COMMIT FLOW 




25 



2512 



25/29 



\ 




CLIENT DRIVES A REMOVE ^ 
AGAINST THE OBJECT 


\ 




1 COMMIT TRANSACTION | 






CALL UNINITFORDESTRUCTION 
ON BUSINESS OBJECT 


\ 




DELETE DIRECTORY ENTRY 

AND DB2 DATA | 



2600 



2602 



2604 



2606 



v' 



2608 



DELETE BUSINESS OBJECT AND 
DATA OBJECT FROM MEMORY 



T 



2610 



DB2 RECEIVES A PREPARE 
AND COMMIT FLOW 



T 



Y 




(END) 

fig. 26 



I I 



26/29 



C START ^ 



\ 




CLIENT CREATES THE TRANSACTION 






TRANSACTION CONTEXT IS 
ESTABLISHED IN NAME SERVER 
AND ASSOCIATED WITH BO/DO PAIR 


\ 




TRANSACTION CONTEXT IS 
RETRIEVED BY DB2 



2700 



2702 



2704 



I 




(END) 

fig. 27 



27/29 



NAME SPACE 



NAME SERVER 

NAMING 
CONTEXT 
OBJECT 



NAMING 
CONTEXT 
OBJECT 



2802 




LIFE CYCLE 
REPOSITORY 



fig. 28 



2800 




2900 



fig. 29 




2902 



28/29 



r START ^ 



BEGIN TRANSACTION 



REGISTER THE FACTORY FOR 
. IMPLEMENTATION E UNDER 
INTERFACE NAME A 



REGISTER THE FACTORY FOR 
IMPLEMENTATION E UNDER 
INTERFACE NAME B 



REGISTER THE FACTORY FOR 
IMPLEMENTATION E UNDER 
INTERFACE NAME C 



COMMIT TRANSACTION 



T 

(END) 




3000 



3002 



3004 



3006 



3008 



REGISTER THE FACTORY FOR 
IMPLEMENTATION E UNDER 

INTERFACE NAME D 






REGISTER THE 
IMPLEMENTAT 
INTERFAC 


FACTORY FOR 
ION E UNDER 
E NAME E 



3010 



3012 



Jig- 30 



29/29 




1 



A TRANSACTIONAL NAME SERVICE 

This invention relates, in general, to object-oriented computing environments and, in paiticular, to 
providing a distributed, object-oriented computing environment that is reliable, secure, transactional and 
workload managed. 

Object-oriented technology continues to be an increasingly important tool for use in building portable 
application code that can be readily used and reused. A basic premise of object-oriented technology is the use of 
objects. An object is a run-time entity with a specific set of instance methods and variables associated thercwidi. 

In an eflfort to enhance the usabUity. portability, reliability and interoperability of objects, certain 
standards have been created. One group responsible for such standardization is refeued to as the Object 
Management Group (OMG), which is a consortium of different corporations, businesses and users interested in 
promoting object-oriented technology. 

The Object Management Group has taken great steps in its standardization efforts. For example, the 
OMG is responsible for the creation of an object request broker (ORB), which is used to provide 
communications between clients and servers of a computing environment The ORB is based upon an 
architecture touted by OMG and referred to as Ae Common Object Request Broker Architecture (CORBA). 

One goal of the OMG is to provide distributed object-oriented applications and systems that coincide 
witfi the needs and desires of die ever-changing computing industry. This goal includes supporting 
multi-vendor, global heterogeneous networks. 

Aldibugh efforts have been made to meet the goals of the Object Management Group, and of the 
object-oriented industry as a whole, further enhancements are still needed. For example, a need exists for a 
distributed object-oriented computing environment that is reliable, secure, transactional and woridoad managed. 

The shortcomings of the prior art are overcome and additional advantages are provided through the 
provision of a method of managing a name server of a computing environment The method includes, for 
instance creating one or more objects in die name server; and managing the one or more objects as transactional 
objects, wherein the name server is transactional. 

In another embodiment of the present invention, a method of manipulating objects within a computing 
environment is provided. The method includes, for instance, creating an object within a server instance of a 
computing environment; and atomically binding die object witiiin anodier server instance of the computing 
environment. 

As a further aspect of the present invention, a method of manipulating objects widiin a computing 
environment is provided. The method includes, for instance, binding a firet object within a name server of the 



2 



computing environment; and binding a second object within the name server, wherein the binding of the first 
object and the binding of the second object are performed within a scope of a transaction. 

Another aspect of the present invention provides a method of providing access to an object of a 
5 computing environment. The method includes, for instance, requesting access, by a requester, to an object 

located in an address space of the computing envirotmient, wherein the requester is resident within the address 
space; and providing access to the object using a local access proxy located within die address space. 

In one example, the use of the local access proxy provides decoupling of one or more object references 
10 to the object from management of one or more virtual memory copies of the object. As a further example, the 

use of the local access proxy enables the object to be independent of any object references owned by the 
requester. 

In a further example, the requester is one of anodier object located within the address space and an 
1 5 object request broker. 

In yet a further example, the local access proxy uses a reference to the object to provide access to the 

object. 

2 0 The present invention advantageously enables the decoupling of references to the object from the 

management of die virtual memory copies of the object. 

Systems, articles of manu&cture, and program storage device corresponding to the above-summarized 
method claims are also described and claimed herein. 

25 

Embodiments of the invention will now be described with reference to the accompanying drawings, in 

which: 

FIG: 1 depicts one example of a computing environment incorporating and using the c^abilities of die 
30 present invention; 

FIG. 2 depicts one example of a managed object, in accordance with the principles of the present 
invention; 

35 FIG. 3 illustrates one example of an interoperable object reference used in accordance with the 

principles of the present invention; 

FIG. 4 depicts one example of a local access proxy located within a server instance, in accordance with 
the principles of the present invention; 

40 



FIGs. 5-6 depict one embodiment of the logic associated with building a local access proxy for a target 
object, in accordance with the principles of the present invention; 

FIG. 7 depicts one example of a policy set associated with a container of a particular server instance, in 
accordance with the principles of the present invention; 

FIGs. 8a-8b depict one embodiment of the logic associated with activating a managed object, in 
accordance with the principles of the present invention; 

FIG. 9 depicts one example of an object transaction service and resource recovery service coupled to a 
server instance, in accordance widi the princq>les of the present invention; 

FIG. 10 depicts one example of a container managing an object, in accordance with the principles of 
the present invention; 

FIG. 1 1 depicts one example of a connection object associated with a container and used in accordance 
with the principles of the present invention; 

FIG. 12a depicts another example of components of a server instance, in accoidance with die principles 
of the present invention; 

FIG. 12b depicts one example of composed containers and composed data objects used in accordance 
with the principles of the present invention; 

FIG. 13a d^icts one example of a multisystem environment, which uses the c^abilities of the present 
invention; 

FIG. 13b depicts the multisystem environment of FIG. 1 3a with die addition of location service agents, 
which are used in accordance with the principles of the present invention; 

FIG. 14 depicts one embodiment of the logic associated with selecting an appropriate server instance to 
perform a particular task, in accordance with the principles of the present invention; 

FIG. 15 depicts one embodiment of die logic associated with ensuring that a given unit of work arrives 
at an appropriate server instance, in accordance with the principles of the present invention; 

FIG.. 16a depicts one example of a distributed name space, in accordance with the principles of the 
present invention; 



FIG. 16b depicts one example of a non-distributed name space, in accordance with the principles of the 
present invention; 

FIG. 17 depicts one embodiment of a hierarchy of naming contexts within a name space, in accordance 
with the principles of the present invention; 

FIG. 18 illustrates one example of the inheritance and delegation relationships associated with the 
components of a managed object, in accordance with the principles of the present invention; 

FIG. 19 depicts one example of a schematic illustration of different naming contexts being backed by 
different resources managers, in accordance with the principles of the present invention; 

FIG. 20 depicts one embodiment of the logic associated with handlmg disjunct bindings, m accordance 
with the principles of the present invention; 

FIG. 2 1 depicts one embodiment of the logic associated with mapping a CORBA name to an object's 
identity, in accordance with the principles of the present invention; 

FIG. 22 depicts one embodiment of the logic associated with creating a primary key for new objects, in 
accordance with the principles of the present invention; 

FIG. 23 depicts one embodiment of a transactional name server, in accordance witfi the principles of 
the present invention; 

FIG. 24 depicts one embodiment of the logic associated widi creating an object for a transactional name 
server, in accordance with the principles of the present invention; 

FIG. 25 depicts one embodiment of the logic associated with updating an object of a transactional name 
server, in accordance with the principles of the present invention; 

FIG. 26 depicts one embodiment of the logic associated with deleting an object of a transactional name 
server, in accordance with the principles of the present invention; 

FIG. 27 depicts one embodiment of transactional context flows, in accordance widi the principles of the 
present invention; 

FIG. 28 depicts one embodiment of a name space, which includes a life cycle repository used in 
accordance widi the principles of the present invention; 



FIG. 29 depicts one example of inheritance relationships among various interfaces, in accordance with 
the principles of the present invention; 

FIG. 30 depicts one embodiment of the logic associated with registering multiple interfaces for a 
5 particular implementation, in accordance with the principles of the present invention; and 

FIG. 3 1 depicts one embodiment of a server instance, which includes a server control region and one or 
more server regions, in accordance with the principles of the present invention. 

10 In accordance with the principles of the present invention, an infrastructure is provided that supports an 

object-oriented, component-based programming model and provides for a computing environment that is 
distributed, reliable, secure, transactional, and workload managed. 

One embodiment of a computing environment incorporating and using the capabilities of the present 
15 invention is depicted in FIG. 1. Computing environment 100 includes, for instance, one or more server systems 

102 coupled to one or more client systems 104. In the example described herein, server system 102 and client 
system 104 are based on the Enterprise Systems Architecture (£SA)/390, offoed by International Business 
Machines G)rporation (Aimonk, NY), and described in "Enterprise Systems Architecture/390 Principles of 
Operation", IBM Publication No. SA22-7201-05, SixA Edition (Sept 1998). In otiier examples, however, one 
20 or more of the server systems and/or the client systems may be based on other architectures, including, but not 

liinited to, a UNIX architecture. Further, a server system of one architecture may be coupled to a server system 
and/or a client system of another architecture. 

In addition to the above, in one embodiment, at least one server system 102, as well as one or more of 
25 the client systems, support object-oriented prograirmiing and object-oriented concepts. Object-oriented 

programming and concepts are described, for example, in CORis A A Guide To Common Object Request Broker 
Architecture, by Ron Ben-Natan, McGraw-Hill Publishers (1995), and Object-Oriented Programming Using 
SOM and DSOM, by Christina Lau, Van Nostrand Reinhold Publishers (1994). CORBA is further described in 
"CORBA 2.2/IIOP Specification," available at WWW.0MG.ORG/library/C2INDX.HTML. 

30 

Server system 102 includes, for instance, component broker runtime services 106, which provide the 
infirastructure and capabilities for various aspects of die present invention. In one example, component broker 
runtime services 106 include, for instance, systems management services, managed object framework interlaces, 
naming services. Life Cycle services, transactional services, interface repository services, and location service 

3 5 agent services. These services, as well as others, are used to implement aspects of the present invention, as 

described below. Component broker runtime services may be included in, for instance, a component broker 
product The component broker product may also include and/or implement various aspects of the present 
invention. One embodiment of various features of a component broker is described in "Component Broker 
Programming Reference Release 2.0," IBM Publication No. SC09-28 10-04 (Dec. 1998); "Component Broker 

40 Programming Guide Release 2.0," IBM Publication No. GO4L-2376-04 (Dec. 1998); and "Component Broker 



Advanced Prograimmng Guide Release 2.0," ffiMPublicati^^ Component 
broker and/or component broker nmtime services may be sold separately or packaged widi an operating system. 



Server system 102 also includes one or more resource managers 108, which own and control a set of 
resources within the computmg environment; and at least one operating system 1 10. which controls the 
operation of the server system. 

One example of a resource manager is a database management facility, such as DB2, offered by 
International Business Machines Corporation (Armonk, NY). DB2 is described in "OS/390 Version 5 Release 
Guide," IBM Publication No. SC26-8965-01 (June 1997), Data managed by DB2 may be stored on external 
storage 1 12 (e.g., direct access storage devices (DASD)) coupled to server system 102, 

One example of operating system 1 10 is the OS/390 or Multiple Virtual Storage (MVS) operating 
system offered by International Business ^4achines Corporation (Armonk, NY). OS/390 is described in "MVS 
Programming: Assembler Services Guide," IBM Publication No. GC28-1762-01, Second Edition (September 
1996), and "MVS Programming: Assembler Services Reference," IBM Publication No. GC28-1910-01, Second 
Edition (September 1996), 

In accordance with one aspect of the present invention, operating system 1 10 includes at least one 
mstance of a server 1 14, which is, for example, a software process defined witiiin server system 102. Each 
server instance is in one or more address spaces and is defined using, for example, one or more graphical user 
interfaces (GUI) provided by component broker nmtime services 106. The graphical user interface(s) provides 
options, which enable the server instance to be named and to be associated with certain characteristics (e.g., is 
the server instance to be secure, workload managed, etc.). The information presented on the GUI is stored in a 
database, such as a DB2 database. Subsequent to defining die server, the server is created by using, for instance, 
an address space create, which pulls the requisite information from the DB2 database. 

Server instance 1 14 includes various components such as, for example, one or more objects 1 16, one or 
more containers 118, and at least one object request broker (ORB) 120. Each of the components of server 
instance 1 14 is described in further detail below. 

Object 1 16 is a run-time entity (e.g., application code) with a specific set of instance methods (i.e., 
functions to be perforaied on tiie object) and instance variables (used to store data specific to the object) 
associated therewith. 

One example of an object is a managed object 200 (FIG. 2), which includes various components, such 
as a business object 202, a data object 204 and a key object 206. Managed object 200 is created via a managed 
object framework, which includes a set of interfaces that is inherited. Pieces of the managed object firamewoik 
are inherited by the business object, when it is created, which enables the business object to reside in server 
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instance 1 14. As one example, business object 202 inherits an interface from the managed object framework 
called "managed object with data object." This provides data object 204. 

Data object 204 is a helper object to the business object It is not exposed to the user of the business 
object hicluded within the data object is the means to reference the data (e.g., SQL for DB2 data). That is, the 
data object includes a schema map. It is the object responsible for going to the database, retrieving the requested 
information, and passing die information on to the business object 

A set of methods is introduced on the "managed object with data object" inter&ce» which includes, for 
instance, an initForReactivation method, a initFoiCreation mediod, an uninitForPassivation method and an 
uninitForDestmction mediod. These methods are driven on the business object after or before the containa- 
performs a function. It is the container that manages the object in virtual memory. These methods are used to 
tell die business object what the container has done and to give die business object a chance to do processing as 
a result of the container managed event 

In particular, the initForReactivation and initForCreation methods are used to bring a virtual memory 
image of a managed object into memory and to initialize it, as described fiuther below. The 
uninitForPassivation mediod is used to remove the image of a managed object from virtual memory; and the 
uninitForDestmction method is used to delete a managed object from the backing store (e.g., die DB2 database), 
also described frirtfaer below. 

The implementer of the business object is responsible for implementing the above-described methods. 
For example, assume an application developer wishes to build an implementation of a business object of Type 
A. The application developer uses an inter&ce for Type A that inherits the "managed object with data object" 
interne. That interfece provides the inheritance for the four methods, for which the application developer has 
provided implementations. 

The application developer also provides an implementation for key object 206, which is associated with 
the business object The key object includes a key value used to identify the managed object from other 
managed objects within a home collection. 

In one embodiment, all of the provided implementations are compiled, linked and packaged into a 
dynamic linked library (DLL). The DLL is supported by an object referred to as a home collection object built 
by a[ systems management application. 

In particular, each managed object Uves in a home, which is identified by a name and has a defined set 
of properties associated therewith. The relationship between die home and information in the DLL is 
represented by a set of systems management metadata in the form of data definition language (DDL). The DDL 
includes, for instance, the name of the home, the properties of the home, and the name of the container 
(described below) that is going to support the DLL. Additionally, the DDL includes the name of the business 
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object class, the name of the data object class, and the name of die primaiy key class. The DDL package is 
imported into a systems management application. The systems management application ensures that the named 
container exists (i.e., there is a systems management definition) and then builds the home collection object to 
support the DLL. The home inherits from the container that it is attached to, so there is a merge of the home and 
the container. Thus, there is a merge of the metadata. 

Returning to FIG. 1 , server instance 1 14 also includes one or more containers 118. A list of the 
containers associated with the server instance is built and stored in, for instance, a DB2 database during creation 
of the server instance. In one example, each server instance has a root container that is bootstrapped to the 
server instance and manages any other containers associated therewith. Similar to the server instance itself, each 
container is defined using, for example, one or more graphical user interfaces provided by component broker 
runtime services 106. Using the GUI, the container is named and any policies associated dierewith (as described 
below) are defined. Once again, the definition is stored in DB2. Additionally, the relationship between the 
server instance and the container is stored in DB2. 

Each container is used to locate one or more managed or business objects (referred to herein simply as 
objects) that are associated with the container. That is, the container is considered a home to the one or more 
objects. The container is able to locate an object using the object key provided to &e container by, for instance, 
object request broker 120. If die object is not in virtual memoiy, die container brings die object into virtual 
memory from storage (e.g.. a database) and materializes the object The container then passes the virtual address 
of the object to object request broker 120. since it was the object request broker that passed the object key to the 
container. When die ORB receives the address, it can dien dispatch methods onto that object. 

Object request broker 120 is responsible for managing communications between a server instance and a 
remote client. In particular, the ORB receives requests from a remote client, determines the object that is being 
requested and drives die requested mediod on diat particular object In order to locate the object, die object 
request broker passes die object key to die container, which then locates die object for the object request broker. 

A remote client is located, for instance, in client system 104, which includes one or more clients or 
client instances 128 managed by at least one operating system 130. Operating system 130 is, for example, die 
OS/390 operating system offered by International Business Machines Corporation. In odier examples, operating 
system 130 is Windows NT, AIX or any otiier operating system tfiat can be employed widi the present invention. 

A client includes, for example, one or more applications 132, one or more remote access proxy objects 
134 and a client object request broker 136. 

Application 132 initializes requests to objects located widiin a server instance 1 14 of server system 102. 
Each request includes an interoperable object reference 300 (FIG. 3), which provides die identity of the object 
and the identity of the server instance in which the object resides. In particular, interoperable object reference 
300 includes, for instance, a header 302 providing mformation regarding die object, including its type; network 
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addressing information 304 providing location information for the server instance housing the object; and an 
object key providing the identifier (i.e., key) of the object. 

When an application issues a request, the request is intercepted by remote access proxy object 134, 
which is coupled to the application and to ORB 136. The remote access proxy object gives the client application 
the illusion ^t the client application is driving a method on a local object instead of a remote object. The 
remote access proxy object passes the request to ORB 136, which forwards the request to ORB 120 of a given 
server instance via, for instance, a TCP/IP connection 138. ORB 136 knows which server instance to send the 
request to, since the server instance is identified in network addressing infomiation 304 located within the 
interoperable object reference, which is passed with the request. 

The interoperable object reference is provided to the client as a result of a response to a request by the 
client or as some inbound parameter. For example, the interoperable object reference may be provided to the 
client by a naming service, as described further below. When the interoperable object reference is imported into 
the client*side ORB, the client-side ORB recognizes it as an object reference and interrogates it to determine 
what should be done with the reference. Since it is an object reference, ORB 136 builds a remote access proxy 
object, associates die addressing information with the proxy and hands the viitual address of die r^ote access 
proxy object to die application that wants to use it Thus, when the application drives the object, it talks to the 
proxy, which proceeds to the client-side ORB. The client-side ORB then uses the network addressing 
information stored in the lOR of the proxy object to locate the server instance, and to pass to the server instance 
the object key as opaque data. Thus, the proxy object, which resides in a client, represents a network-wide 
reference to the target object, which resides in a remote server instance. 

As described above, the remote access proxy object is used to drive the client-side object request broker 
in order to deliver method requests to the target object, which resides physically in another address space 
somewhere in the network. Because the client application does not use an actual virtual memory address of the 
target server object, the life cycle of the physical object resident in die server instance can be independent of the 
number of outstanding client references to the object 

However, in die case where the client (i.e., the requester) of the target object resides physically in die 
same address space as the target object itself, it is common practice to represent the reference to the target object 
with a virtual memory pointer, since there is no requirement for an object request broker interaction. ORBs are 
conventionally used only to provide commuiucation across different application processes (Le., across different 
address spaces), not to facilitate communication within the same application server process (i.e., the same 
address space). Therefore, for the local access case, die life cycle of the target object is tightly bound with die 
tracking of the outstanding local references to the object. 

There are a number of problems associated with binding the life cycle of the target object with the 
outstanding local references. First, die principle of local/remote transparency is broken, since the local 
references to an object behave differently dian die remote references. Second, die approach constrains the 
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management of the virtual memory resident copy of the target object and makes memory residency dependent 
on the number of outstanding local references. Third, since physical copies of the target object are tied directly 
with a virtual address pointer in the client application, certain instance management policies which determine 
such things as activation, and isolation level at various execution contextual boundaries cannot be implemented, 
since there can be no assurance that reference to the object will not be used by multiple units of work rmming in 
difference execution contexts. In other words, sq)arate cached copies of the target object cannot be provided by 
the instance management component (e.g., container) of the server instance (described below), since shared use 
of the reference results in shared use of a single cached copy of the object. 

Based on the foregoing, a need exists for the decoupling of the local object references torn die 
management of virtual memory copies of the target object widiin the instance management container. Further, a 
need exists for allowing objects to be independent of (e.g., not bound) to any address pointers owned by the 
client application (i.e., the requester). Thus, in accordance with one aspect of Ae present invention, a local 
proxy is added to a server instance, so that any access to the target object whetficr remote or local within an 
address space is managed through a proxy. 

The addition of a local proxy on a server instance for local access is depicted in FIG. 4. A local access 
proxy 400 enables one object 402 (e.g., a managed object or a business object) or the ORB in a server instance 
114 to drive anodier object 404 (e.g., a managed object or a business object) in the server instance in a manner 
similar to an implication in client 128 drivmg an object m serv«- instance 1 14. Advantageously, fins provides 
for local/remote transpaiency in that an object can be driven in the same manner regardless of whedier the 
access is local or remote. 

One example of die logic associated widi building a local proxy is described with reference to FIGs. 
5-6. Initially, a requester, such as the ORB, that wishes to obtain a pointer to a managed object (e.g.. Object B) 
from an object reference, passes an object reference to the root container andrequests a managed object pointer, 
STEP 500 (FIG. 5). Specifically, in one embodiment, the entire object key value is passed to the root container. 
The object key value is the hierarchical name key path of the target managed object. For instance, an object key 
value might be "root/containerl/ 123456", where "root" is the key of the root container, "container!" is the key 
of the container holding the managed object, and "123456" is the key of the managed object within the 
container. 

The root container strips off its part of the key, and passes die rest of the key to the next container, e.g., 
containerl , STEP 502. Containerl then strips off its part of the key, STEP 504. 

As part of the local proxy support, containerl dicn builds a local access proxy, STEP 506, and returns 
the address of the local access proxy back to die requester, STEP 508. 

In one example, in order to build the local access proxy, die container (e.g., containerl) first determines 
through its configured metadata die type of object being managed (e.g.. Type B), STEP 600 (FIG. 6). The 
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container goes to a class manager 406 (e.g., a table that represents a list of interface names) to retrieve any 
necessary information. For example, the container retrieves an entry for a local proxy factory, loaded by the 
DLL, to produce local proxies of Type B. STEP 602. The container drives a request to that proxy factory and 
obtains an instance of Local Proxy B, STEP 604. Local Proxy B is created and die address of the proxy is 
passed back to the calling object (eg., the ORB). (In another example, a proxy for an object, such as Object A, 
did the actual calling and thus, the address of Proxy B is passed to the proxy for Object A, which dien passes it 
to Object A). 

When the requester receives the address of the local access proxy, the requester then issues another 
request, which now goes to the local access proxy, which communicates with the target object In particular, in 
one embodiment, the local access proxy object consults with the container (e.g., containerl) to obtain the actual 
virtual memory address of the target maiiaged object. To obtain this address, the local access proxy passes the 
target object's primaiy key to the container. 

Described in detail above is the use of local access proxies to access objects, including those resident in 
the same address space as the requester of the objects. In one aspect, when using local access proxies, it is 
generally the case that use of an object reference is to include the appropriate use of &e "dupe" and "release" 
CORBA methods. In fact, in one embodiment, the use of "t-var" is recommended as a means to hold references 
to CORBA objects. This recommendation applies whether access to the managed object is local or across an ' 
ORB boundary. The VAR causes the release of die proxy, when it goes out of scope within a C++ program. 

The approach described herein allows the local access proxy to dynamically switch to die appropriate 
target object, while allowing the container to manage its activated objects in accordance with its designated 
policies. In particular, the local access proxy is capable of proceeding to its container to find out what object it 
is to drive, which is based on the underlying context in which it is being driven (in real-time). This allows the 
container to manage the objects in accordance with its policies. In one example, the container is consulted, both 
before and after, each method dispatch of a managed object. This consultation occurs fix>m the local proxy. The 
container ensures no change to the disposition of the activated managed object occurs between die "before" and 
"after" calls from the local proxy. 

Those policies govern not only the life cycle of the in-storage copy of the object, but also die physical 
isolation levels implemented by managing multiple copies of the target object, each associated with a specific 
execution context, such as a transaction or a session. By making memory residency of the target object 
independent of the number of outstanding local references to the object, the container is able to page-out objects 
to more effectively manage server instance virtual memory, v/hile at the same time provide the trigger 
mechanism to cause the page-in of the object, if the object is referenced by the client application. 

In accordance with one aspect of the present invention, a set of management policies, selectable by the 
customer at object installation time is provided (e.g., when the container is defined). These policies govern the 
management of state coherency, isolation level and residence lifetimes of both transient and persistent objects in 
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the virtual memoiy of a distributed object server, such as server instance 1 14 (see FIG. 7). The policies 700 are 
managed by one or more containers 1 18 and include, for instance, an activation isolation policy, a passivation 
policy, a flush policy and a refresh policy, each of which is described below. 

Activation is the process by which a virtual memoiy image of a managed object (or a business object) 
is brought into memory and initialized via, for exan^jle, an initForReactivation method or initForCreadon 
method. Activation is an implied action taken when creating a managed object with a managed object factory. 
The process of activation is architecturally independent of transaction management, session management, 
locking etc. Activation is the instantiation of an object image in virtual memory and the attachment of the object 
to either an ORB or a local access proxy, so that the object is physically ready for client driven methods. 

For example, assume there is an object referred to as an employee object. Employee 1 , and a method 
referred to as Increase Satery is to be driven on that object Also, assume that the state of Ihe object is persistent 
and lives in a database coupled to the server environment The object has a unique identity, such as an employee 
serial number, which represents the primary key of the object In particular, the primary key is part of the object 
key, and the object key includes a set of infonnation that represents a hierarchical path from the root container in 
a given server instance down through the container that manages the particular object, e.g., the employee object 
As an example, the object key for the employee object symbolically looks like die following: Root 
container/employee home primary key value/employee managed object primary key value. 

The object key is used to activate the object, as described in the following example with reference to 
FIGs. 8a-8b. Initially, a client packages up a request, STEP 800. The request includes, for example, the 
following information: the name of the method, e.g., Increase Salary, parameters for the metiiod; and an object 
key which was obtained from the interoperable object reference. The request is forwarded to a remote access 
proxy object (assuming the client is in a different address space than die target object), which removes the object 
key from die request and passes the object key and data to die server instance via an ORB, STEP 802. The ORB 
of the server instance receives the object key and the data. 

The server ORB then demarshalls the key in order to fmd the object inside the server instance that the 
method is to be dispatched thereon. In particular, the ORB takes the object key and proceeds to the root 
container (the ORB knows where the root container is, since it is hardwired into die server instance) and drives a 
mediod called KeyToObj on the contamer, STEP 804. The ORB does tiiis in order to locate an actual object to 
dispatch onto. Specifically, the ORB is lookmg for a virtual memoiy address of a real instance of an object and 
it is counting on die container to hand the address back to die ORB. The address that will be passed back to die 
ORB is, however, in accordance with one aspect of die present invention, a pointer to a local access proxy, 
instead of the actual object 

Continuing with FIG. 8a, when die root container receives die object key, it strips off die object key of 
die object that is to be located. STEP 806. hi diis example, die employee home container primary key value is 
stripped off and die root contamer determines whedier diat employee home container is active. INQUIRY 808. 
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In one example, the root container detennines whether the container is active by taking the key value and 
searching a hash table for that value. If the vahie exists in the hash table, then the container is active. 

Should the container be inactive, dien it is activated, STEP 8 10. In one example, activation of the 
container is the same process as activating a managed object The process is recuisive and can occur at any level 
in the container tree. 

If the home container is active or after it has been activated, then a further determination is made as to 
whether the container is within &e scope of the policy associated therewith, INQUIRY 8 12. Again, in one 
example,thisisaccomplishedby using policy information stored in the hash tables. Should the container not 
be within the scope of the policy, dien an exception is i»ovided, STEP 8 14. 

However, if the container is within the scope of its policies, then a determination is made as to whether 
another container is to be located, INQUIRY 816. In particular, a decision is made as to whether the container 
for the particular key value is the cturently processed container. If not, then the procedure recurses down 
another layer. In particular, the rest of the object key is forwarded to the container, and the KeyToObj method is 
driven, once again, STEP 804. 

Returning to INQUIRY 816, once die appropriate container to manage die employee object in this case, 
is obtained, the container builds a local access proxy for this class of object, STEP 818. The container knows 
the class of object by the information stored in die DB2 table associated therewith. That is, the container is 
aware of the managed object class name, the business object class name, the policies and a local access proxy 
class. Thus, the container brings up a local proxy for the specific employee identified by the primary key. 

Subsequendy, the container passes a pointer to the local access proxy back to its caller which is the root 
container, in this one example, STEP 820. Once die caller receives the pointer to the local proxy, it can then 
di^atch thie managed object dirough the local proxy, as described widi reference to FIG.8b. 

Initially, the requester drives the method represented on the local proxy, STEP 822 (FIG. 8b). Then, 
die local proxy consults the object's container to obtain the address of the managed object, STEP 824. 

Subsequendy, the container enforces its dispatching policy and selects a virtual memory copy of the 
object to be dispatched, STEP 826. This selection is based upon activation isolation level etc., and may result in 
the activation of the object. In one example, the policies are cached within the container, when the container is 
activated. The activation isolation policy includes, for instance, three levels: transaction level, session level 
and container level. 

At the transaction level, a specific virtual memory image of the managed object is activated for each 
transaction accessing the object. Any thread of execution running in the server instance within the transaction 
may share the same activated managed object. This includes muhiple direads, as well as different threads 
running on the transaction either as a result of an object request broker managed context switch or a resume 
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operation, which made a given transaction active on the thread. However, any thread running outside of the 
transaction does not share the same virtual memory copy of the managed object. 

At the session level, a specific virtual memory image of the managed object is activated for each 
session accessing the object Any thread of execution running within die server instance within the session, 
including those running in different sessions, may share the same virtual memory copy of the object. However, 
any thread nmning outside of the session does not share the same virtual memoiy copy of the managed object 

At the container level, only one virtual memory copy of the managed object is activated at any one time 
within the container within the server instance. Any session and transaction running within the container may 
share the same virtual memory copy of the managed object 

Assume, for ©cample, that the policy is to activate an object per transaction. The container realizes that 
it is isolated at transaction, so the container determines which transaction it is running under. This is 
accomplished by consulting the transactional context hanging off of the execution thread associated with the 
request. If, for instance, it is determined that die transactional context is Transaction 7, then Ae container 
references the hash table (e.g.. DB2 table) and uses the primary key value of the object, along with the 
information of Transaction 7, to determine if the object is activated in memory. If there is no object having that 
primary key value for Transaction 7, then the object is created. 

In particular, die object can be created from scratch or the container can have pools of objects (e.g., hot 
cached shells of the objects) used to obtain an instance of the managed object As one example, an instance of 
the managed object, the data object and the primary key object is obtained. 

After obtaining tiie instances, the container takes the primary key value and passes that value to the 
primary key object That is, die primary key object is constructed by handing it its state. The primary k^^ 
object mitializes itself using a FiomString mediod. The primary key object is dien handed to the data object 
with a call "IntemalizeFromPrimaryKey". The data object retrieves whatever information it needs to identify 
this object. For example, the data object retrieves die primary key value so diat it can go to a DB2 database with 
an SQL select 

Thereafter, die coniainer drives a mediod on die data object called a RetrieveFromDataStorc mediod. 
The data object takes die primaxy key vahie, plugs it into a select statement (e.g., SQL) because it is a retrieve 
mediod and goes out to die database, fetches the appropriate row, brings die data in, and places it in die data 
object. Once this is accomplished, the data object validates that die object actually exists. Thus, the data object 
takes die primaiy key and goes to die database and hands back to die container some indication diat die object is 
out there. 



Next, die container drives die initForReactivation mediod on die business object handing die business 
object die data object The business object saves die latest data object and at diat time can perform whatever 
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function is necessary to initialize itself. The business object then returns to the container and the container 
passes back to the local access proxy the actual address of diis activated object. 

After the container selects the virtual memory copy of the object, the local proxy delegates the method 
request to the actual managed object, whose address was obtained firom the container. STEP 828. The managed 
object performs its business function and returns to the local proxy, STEP 830. 

Thereafter, the local proxy consults with the container again to allow the container to do any cleanup 
after the method execution, STEP 832. Furdier, the local proxy returns to the requester. STEP 834. 

In addition to the above, during object activation, the container also registers itself with an object 
transaction service (OTS) 900 (see HG, 9) as an OTS synchronization object (OMG OTS is described in 
CORBA services specification available on the OMG web page (WWW.0MG.ORG) under technical library.) 
That is, the container places various information in a table associated wiA OTS. As shown in FIG. 9. OTS is 
coupled to a resource recovery service (RRS) 902 located widiin the operating system. Since the container is a 
synchronization object, it in^)lements a "before completion" mediod and "after completion" method. Thus, as 
one example, when a transaction is ready to be committed, OTS uses the sync object to inform its objects that a 
commit is about to happen ("before completion**) and that it has happened ("after completion"). 

Additionally, OTS passes the conunit to RRS 902, which is responsible for driving the commit to any 
resource managers coupled to the server instance. It is the resource manager(s) that is ultimately responsible for 
performing die commit When the commit is done. RRS returns to OTS and indicates completion. 

In one embodiment, as part of a transactional conmiit, the objects are passivated. Passivation is die 
opposite of activation. Passivation is die ability to push die data back out to the database and to eliminate the 
vurtual memory copy of the data. In particular, the before completion method on the synchronization object 
causes data to be pushed to die database. This enables updates to be made, prior to RRS informing die resource 
manager to start the 2- 
phase commit process. 

Passivation is the act of removing an image of a managed object from virtual memory within a server 
instance, so as to detach it from die object request broker or die local access proxy. The use of a local access 
proxy gives die container die ability to passivate the object based on die appropriate policy, instead of having to 
keep track of die various pointers to the object When a container decides to passivate an object, die container 
pushes die object's data back to the resource manager, such as DB2. The managed object is notified of 
passivation via an uninitForPassivation mediod or an uninitForDeletion mediod. Deletion of a managed object 
implies die act of passivation before die object is formally deleted. Passivation may be triggered at different 
times and for different reasons not relevant to die act of passivation itself In die case of transient objects widi 
no backmg resource manager odier dian die container itself, passivation implies deletion of die managed object. 
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A management policy associated with passivation is referred to as a passivation policy, and it includes, 
for instance, four options: pinned, pinned for tfie life of the session, pinned for the life of the transaction, and not 
pinned. 

Pinned indicates diat the managed object is never passivated. In order to make Ac managed object 
unavailable to a cUent driven method dispatch, the managed object is deleted (i.e., removed). Transient objects 
are typically pinned, although this policy may also be ^plied to persistent objects (e.g., objects in which tiieir 
data are stored in a backing store), as well The container may remove the activated object from virttial memory 
in the case where a refresh of the managed object has failed due to the object being deleted. This may occur in 
loosely coherent systems when a client application has deleted the managed object within a replicated server 
region other than the current one. 

Pinned for the life of the session indicates that the managed object is passivated within a server 
instance, when no sessions are associated with it Note that session suspension from the thread of execution 
does not result in the disassociation of the session with the managed object Session association is the action 
rcsuhing from a thread of execution nmning within a given session touching the managed object That 
association lasts for the life of the session. 

Pinned for the life of the transaction indicates that the managed object is passivated within the server 
instance, when no tnmsactions are associated with it Note that transaction suspension from the thread of 
execution does not result in the disassociation of the transaction with the active managed object Transaction 
association is the action resulting from a thread of execution running within a given transaction touching the 
managed object. The association lasts for the life of the transaction. 

Not pinned indicates that the managed object may be passivated at any time prior to the end of die 
transaction at die discretion of the container. Further, the managed object is passivated when no transactions are 
associated with the managed object. 

In one example, prior to passivating a managed object, the object is flushed in order to push the 
changed essential state of a managed object to its backing resource manager. In one example, the essential state 
of the business object is kept in the data object and accesses to the essential state are delegated to the data object 
This is known as a delegating pattern. This pattern is designated through die inheritance of the 
managedObjectWithDataObject interfece. With this pattern, the essential state is pushed through the execution 
of an update operation on the data object. 

' However, in another example, the essential slate of the business object is resident in die business object 
and not the data object. This is known as a caching pattern. This pattern is designated, if the business object 
inherits the managedObjectWithCachedDataObject interface. In this case, a synctoDataobject method is driven 
on the managed object just prior to driving die update data object operation. In particular, the 
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syncToDataObject method is driven by the container to cause the business object to push its cached slate to the 
data object before the methods on tbe data object are driven to further push the data to die resource manager. 

Id addition to the above, a managed object may be flushed several times uidepend^t of and prior to 
passivation. As a further example, a managed object is flushed as a resuh of a session checkpoint operation, if 
the managed object is associated with the session being checkpointed. 

Other expUcit flush policy options may also be provided. For example, one policy option indicates that 
flushing is to be perfonned at the end of transaction. With this policy, the data object update operation and 
corresponding syncToDatastore operation are driven each time the container recognizes the end of a registered 
transaction, which has been associated with the managed object. The end of transaction poticy applies to each 
transaction accessing the instance, even if die instance has been activated under an activation isolation policy 
which allows multiple transactions to be running concurrently on the same shared virtual memory copy of the 
managed object Therefore, a single activated managed object may be flushed multiple times widiin multiple 
concurrent transactions under the respective policy options. 

As a further example, no explicit flush policy is defined If this is the case, then the flush operation is 
perfonned at the time of passivation and as a result of a session checkpoint operation. 

A managed object may also be re&eshed. Managed object refresh is the logical action resulting from 
the execution of a retrieve operation on the data object associated with the managed object The retrieve 
operation is responsible miiumally for ensuring the existence of the managed object's essential state in the 
backing resoiuce manager based upon its identity and as represented by the primary key value of the managed 
object. In addition, die retrieve method may obtain part or all of the essential state of the managed object from 
the associated backing resource managers. In die case of die cached managed object (i.e., a managed object with 
a cached data object), a syncfromDataobject operation is also driven on the managed object during refresh, after 
the retrieve operation has been driven against the data object The syncfromDataobject method is the opposite 
of the synctoDataobject method. The syncfromDataobject method is driven by the container to request the 
business object to retrieve its cached essential state from the data object. 

A managed object is refreshed as part of die process of being activated. In addition, die managed 
object may be refreshed, while in the activated state and may be refreshed a number of times before it is 
passivated. As an example, the managed object is refreshed as part of a session reset operation, if the managed . 
object is associated with the session being reset 

In addition to the above, explicit refresh policy options may be provided. These options include, for 
example, refresh at transaction recognition, at session recognition and no policy. At transaction recognition, die 
data object retrieve operation and corresponding syncFromDatastore operation are driven each time the 
container recognizes a new transaction on the du'ead of execution touching the object 
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At session recognition, the data object retrieve operation and corresponding syncFromDatastore 
operation are driven each time that the container recognizes a new session on the thread of execution touching 
the object. The refresh policies apply even if the object instance has been activated under an activation isolation 
policy which allows multiple transactions or sessions to be running concurrently on the same shared virtual 
memory copy of the managed object Therefore, a single activated managed object may be refieshed multiple 
limes within multiple concurrent transactions and sessions under the respective policy option. 

When no explicit policy is defined for refresh, then refi«sh occurs at die time of activation. 

In one embodiment, in order to define or associate any policies witii the container, a systems 
management application provided by component broker runtime services is used. This application provides, for 
example, a list of the policies that can be selected for a container, and allows the appropriate poHcies to be 
chosen. The chosen policies for tiie designated container are then stored in a systems management repository 
(e.g.. a DB2 database). 

Active in-memory instances of objects within a server instance are managed by a container 1000 (FIG. 
10). One responsibility of the container is to provide a persistence mechanism so that an in-storage object 1002 
can be populated witii essential state fom an external data source 1004. such as a database, and then stored back 
to tiie database, such tiiat any changes to the object become persistent. Often times, however, the facilities 
provided to make an object persistent are accompanied by otiier related functional requirements, such as 
concurrency control, which is a mechanism for locking or serializing the essential state of tiie object, so that tiic 
contents of the object are stable and observable within the context of a given unit of activity, such as a 
transaction; access control, which provides security; and conunit control under a transactional unit of work, 
which controls when changes are to be committed or rolled back. Furtiier, it is often the case tiiat for enterprise 
class data systems use of the data in a database is not exclusive to the object using it Many times, the same data 
is used by various types of applications concunwitly, some of which execute in more traditional types of 
environments, such as in CICS or IMS (offered by International Business Machines Corporation), which are 
outside of the scope and management of the object server instance or system. This data is typically controlled 
through various types of policies, which govern control of access to the data (i.e., security), sharing of the data 
across multiple users and systems, concurrency control of the data, and transactional recovery of the data. 

Conventionally, a container is built in an object server instance based upon the premise that persistent 
objects live in the object server instance and are simply composed from data tiiat lives in a database. When tius 
view is taken, the object server instance takes on the responsibility for hosting and executing the types of 
policies described above. For example, typical object server implementations provide a locking service to 
perform concurrency control of the object within the object server instance. The object server instance assumes 
a similar responsibility for access control of the object. There are a number of problems associated with this 
approach, however. Some of these problems are enumerated below: 



1 ) Building a scalable lock manager is complicated and error prone. 
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2) Building a scalable multi-system lock manager is even more complicated and error prone. 

3) Because the data being used to populate the object is also being used for other puiposes in the 
system, any locking function done in the object server domain must then be reconciled witfi locking done in die 
database management domain. 



4) Many times the access control policies resident in the object server domain are replicas of the 
access control policies in the data management domain, adding performance degradation to the mntime and 
systems management cost to the customer. 

5) Building a recoverable resource manager is complicated and enor prone. Providing this 
function, including the transactional logging required to support it, in die object server is often duplicating 
function that is required in the data management domain anyway. 

6) Providing efficient caching of the object state across transaction boundaries in the object 
server domain requires a reconciliation of die caching policies provided in the data management domain. 
Further, in the case of a clustered systems configuration, the caching is to be reconciled across multiple systems. 

In order to eliminate die above problems, various aspects of instance management are delegated from 
container 1000 to one or more underlying resource managers 1006, such as DB2 offers by International 
Business Machines Corporation (Annonk, NY). In particular, the responsibility for locking (e.g., concuirency 
control), access control, caching across multiple systems (i.e., multisystem caching), and commitment control is 
delegated to the underiying data manager. As such, the object server instance is no longer considered the home 
for an object, but instead, is considered a temporary dispatehing space for die persistent object, which is staged 
or cached into die object server instance fiona its persistent home.in the database. 

Thus, when a request is made by the object server instance to obtain one or more attributes of die object 
(e.g., for an employee object, die attributes may include name, salary, department, etc.), so diat it can be 
composed/staged for dispatch in die object server instance virtual m«nory, die resource manager, instead of die 
container, performs and/or manages any locking, multisystem caching, access control and commitment control 
needed to obtain die attributes. This, in combination widi instance management policy, which, for example, 
provides for a separate copy of die staged object in virtual memory per transaction, eliminates die need to 
provide concurrency control widiin die object server instance, since locking is typically managed at transactional 
boundaries widiin the resource (or data) manager. 



The object is effectively serialized du-ough whatever locks are held in die underiying resource manager 
for each of die object's attributes. Furdier. die locks diat are held in die resource manager domain are providing 
concurrency control across multiple systems in a clustered configuration. It also allows the resource manager to 
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negotiate the compatibility state of the locks in real time as other requests (either from other object servers or 
traditional transaction environments, such as CICS or IMS) are made for the data. 

The same placement of responsibility exists with respect to security. Access control is provided by the 
underlying resource manager as the requests are made from the object server instance to buUd the object in 
virtual memory for use by a given user. The same placement of responsibility exists with respect to data caching 
and recoverable commitment control. There is no need for the object server instance to provide resource 
recovery and logging, since that function is pushed down to the underlying resource manager. With respect to 
caching, the object server instance does not take responsibility for holding state in its vimial memory beyond the 
point at which the state could become invalid in the underlying resource manager. This treatment is only 
overridden through designation of specific policy in the object server instance. Another advantage of this 
^proach is that any ongoing improvements and fimctional extensions provided in the underlying resource 
manager are immediately leveraged transparently in the object server instance. 

In order to delegate tfie various aspects of instance management from a container to a resource 
manager, particular contexts are provided in object space, so that they can be provided on the interfaces used to 
access the resource manager(s). As one example, it is the object request broker that sets up a particular context 
on a thread of execution, thereby pushing the management responsibilities to the resource manager(s), rather 
than having the containers implementing the responsibilities themselves. This is described in further detail 
below with reference to FIG. 11. 

As one example, an ORB 1 100 is responsible for dispatching methods on a given thread of execution 
1 102. By extension, the ORB is responsible (at lest initially) for the settip of any execution contexts 1 104 on 
that thread of execution. These execution contexts include, for instance: 

1) A transactional context that identifies the transaction being performed and within which a 
piece of work is completed. The context is represented by a transactional unit of work and it has an identity and 
a state associated therewith. By associating the transactional context with a thread of execution, anything 
running on that thread of execution knows that it is inside the context of that transaction. 

2) A security context that provides a set of credentials that represents some principles or some 
users and those credentials are associated with the thread of execution. This provides an indication of the 
principle or user that is requesting this piece of work. 

3) A performance management context which is associated with workload management for diat 
thread of execution. It describes the policies that are used to allocate resources to achieve the best perforaiance. 

In one embodiment, the ORB attaches the different contexts (e.g., transaction, workload management 
and security) by using a set of services in OS/390 or MVS called context services. In particular, a control block 
called a work context is provided by the context services. For example, a set of application programming 
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interfaces are used that allow the ORB to associate the context(s) with the current thread of execution. This is 
called a context switch* which enables a context to be switched onto a diread or switched off of the thread. It is 
up to the individual work manager (the ORB in this instance) to set inside the context the correct identities, tags, 
names or whatever is needed to represent those contexts. Then, as the work unit (the thread of execution) flows 
across different environments, the resource managers come to the work context to find the data, which is located 
at architected places widiin the context. Context services is further described in ''OS/390 MVS Planning: 
Workload Management," IBM Pub. No. GC28- 

1761-07 (March 1999); "OS/390 MVS Programming: Workload Management Services," IBM Pub. No. GC28- 
1773-06 (March 1999); and "OS/390 V2R5.0 MVS Piogranuning: Resource Recoveiy," IBM Publication No. 
GC28-1739-02(Jan. 1998). 

Although the ORB initially sets up the contexts, it is possible for the container, since it is on die 
dispatch path to every method, to be able to change or manipulate those coiitexts based on additional policies at 
the container. As one example, the container can switch from one transaction (e.'g., Tran 1 ) to a new transaction 
(e.g.,Tran2). 

In one example, in order for the container to delegate responsibility for performing certain functions 
(e.g., prq)are to conomit, commit, locking, logging, etc.) to one or more resource managers, the resource 
manager(s) also has to be aware of the transactional contexts. The manner in which this is accomplished is 
described below. 

In one example, when the container is initialized (initForReactivation), the container initializes a 
coimection object 1 108, which is used to couple container 1 106 with a resource manager 1 1 10. In particular, the 
connection object has been linked with a DLL with a specific version of a resource manager attachment 1112, 
e.g., a DB2 attachment called RRSAF. Thus, when the container is being initialized, it initializes Ac coimection 
object and drives an initialize method on this connection object. The coimection object is attached to the 
system's management repository, which indicates which resource(s) are to be attached to this container. In this 
example, container 1 106 is to attach to a particular DB2 subsystem, called XYZ. 

In one embodiment, the attachment of the container to DB2 is perfomied using an API called 
"Identify". Thus, the connection object calls the "Identify" piece of code, which is DB2 supplied. DB2 receives 
the call and determines that it is an identifier over the RRSAF package. Thus, DB2 sets up an RRSAF control 
structure 1 1 14, in this case, on task 1 102. 

With the Identify protocol, DB2 knows what specific threads are going to be talking to DB2. Thus, 
when a thread of execution comes across, DB2 looks that thread up and for that thread goes over to the context 
and finds out what transaction it is in. At that point, DB2 performs similarly to the containers. 
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DB2 also knows that by attachment through RRSAF that DB2 has some special exits. DB2 registers its 
interest in this transaction using resource recovery service 1 1 16. which is tracking the transaction. (RRSAF is a 
part of that service.) 

In addition to the above, the object transaction service 1118 (OTS) coupled to RRS also delegates its 
responsibilities down to RRS. OTS delegates its responsibiUties down to RRS through a set of RRS interfaces 
(e.g., prepare, conunit. write log data interfeces. etc.). TTius. in accordance with one aspect of the present 
invention, there is a delegation of responsibilities in one direction (axis) flirough the resource managers and in 
the other direction (axis) to the underlying operating system. 

Within a distributed object server instance 1200 (FIG. I2a), managed or business objects 1202 are often 
persistent. That is. they are composed from data residing in one or more databases 1204. hi a legacy 
envirorunent, where there exists a variety of data sources, such as DB2, IMS and CICS (all offered by 
International Business Machines Corporation. Armonk, NY), as weB as various oOtet data sources, lhae is a 
need to extract data from these resource managers and use Ae data to provide a persistott object witii its 
essential state. 

In order to accomplish this composition, and also hide the specific location and schema of the data 
being used to populate tiie object, at least one container 1206 and at least one data object 1208 are used. The 
containia- fecilitates flie attachment fiom the object server instance to a resource manager 1210, so dial Ae 
resouices from database 1204 managed by resource manager 1210 can be used to populate ±s object The 
mapping of the specific state in the object to ^ific rows or records in the database is performed in data object 
1208. The data object is a helper object in the object server instance runtime to assist in the management of tiie 
persistent state of die business object and to facilitate die movement of data back and forth from die business 
object to the database over die attachment being managed by die container. 

TypicaUy. the containMS and the data objects are built with a constraint which limits Aeir attachmeait 
and interaction with exactiy one type of resource manager. The problem with this approach is that in many 
cases ttiere is a need to compose a business object for multiple and different types of backend resources. For 
example, a particular business object of type "employee" may obtain die employee serial number and name from 
DB2, but obtain its salary attributes from a VSAM record or from an existing IMS transaction program. If this 
is die case, a typical solution involves either perfonming composition in the application flirough mult^ite 
business objects, each one being managed by a separate container; or by building a composed data object by 
delegating the fimction to multiple odier business objects, again, where each one is managed by a separate 
container and where each one is associatt^ widi its own subordinate data object 

This ^proach leads to perfomiance degradation not only because of die additional padiway of 
dispatching multiple objects over several containers, but also in terms of additional memory being used to hold ' 
the additional objects. In die worst case, where die application is forced to deal wiUi die composition, die 
application developer becomes aware of die specific data type, location, schema, and composition, which 
constrains die design of die application in a way as to jeopardize portability and reuse of die business object 
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itself. Additionally, requiring multiple containers to be used introduces systems management burden that could 
otherwise be avoided. Also, the development process used to create the multiple data objects and the processes 
under which these objects are packaged together to form the support for a single business object becomes 
unnecessarily complex and costly. 

Thus, in accordance with one aspect of the present invention, composed containers and composed data 
objects are introduced. A composed container 1220 (FIG. 12b) is one in which multiple and different resource 
managers 1222 can be configured and driven. The composed container manages a plurality of attachments and 
connections to all of the resource managers required or desired to support the composition of a single business 
object 1224. The corresponding data object 1226 is also composed and supports the various request level 
interactions to the various backend resources required or desired to supply the business object with its essential 
state. This approach simplifies the install and configuration of containers; simplifies and consolidates request 
level interactions in a single data object; improves pathlength because multiple and separate dispatches across 
multiple containers are eliminated; and provides the application developer a cleaner more direct mapping of the 
runtime objects in the application model being implemented. 

In one embodiment, composed container 1220 is implemented using a plurality of connection objects 
1228. Each coimection object 1228 is associated with and coupled to a resource noanager 1222. Foir example, 
one connection object is associated wi& Resource Manager 1 (e.g., DB2) and another is associated with 
Resource Manager N (e.g., IMS)* 

In one embodiment, connection objects 1228 are defined using coimection specifications, which are 
created using, for instance, user interfaces provided by component broker runtime services. A systems 
administrator, as one example, defines a connection specification for each resource manager to be comiected to a 
container. The coimection specification identifies a set of information needed to connect to the resource 
manager. For instance, for DB2, it includes die DB2 subsystem name. 

When a connection specification is defmed, it has a type (e.g., a DB2 connection) and it has a 
coimection object class that is to be used. In addition, for the particular type of coimection, it includes whatever 
information is necessary for the contamer to attach or connect to the backend resource. The connection 
specifications and associated information are stored in a database, such as a systems management repository 
coupled to the server instance. The systems management repository also includes information related to the 
containers. . 

When a container is being initialized (e.g. initPorReactivation), the container is provided with a list of 
one or more coimection specifications. The container selects fi^om this list those connection specifications 
representing resource managers to be connected to the container. Then, for each selected connection object, the 
container retrieves from the systems management repository any information relating to that connection 
specification. This information includes a connection object class name for each connection specification. As 
one example, the class name plus any specific information needed for the connection is passed to the container 
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mastreamed fonnat.Tlie container then createsaconnection object using the co^^^^^ 
imtializes the connection object with the data, such that the container can attach to tte 

DB2). 

During initialization, the container drives an "inir method on the connection object During "init". the 
connection object uses theDB2RRSAFattachment(Le..thepieceofbT«a.y code that has 
connection olqect) to connect vdth the resound nanager. For example, the connection ob^^ 
subsystem name to comiect to the DB2 resound manager. Tlie particular implementati«^ 

object is sullied by each resource manager. 

In one embodiment, each connection object class is hardwired for a specific type of resource manager. 
Each connecdon object hasanumber of interfaces to be implemented including initialization, in whi^ 

anached resource manager is to perfomx whatever ptocesshns is required to attach the server 

resoun* manager address space; identify transaction, in which the comiection object is responsible for 
perfomung any pmcessingrequiml to set upacontext for performing worieunderaspecific given tr^^^ 
(e.g., in DB2. there may beaneed to createalogicalDB2 thread of execution that is tied directly to the current 

transactional unit of work); and uninitialization and unidentify transaction, which are used to perform cleanup , 
processing for their respective events. 

In one embodiment, when a container sees a transaction for the first time, the container registers a 
synchronization object with OTS and also infomui each comH«.tionol^ect that the tiansac 
Depending on the type of attachment, that comiection object may or may not perform an action. For example, 
for DB2, the comiection object creates a DB2 representative of a thread and signs the user on, so that DB2 
knows about the user. In particular, in the comiection object, the transaction is identified and DB2 creates a 
thread and anchors one of its structures onto the RRS context. Thus, when a data object accesses DB2. the data 
object pulls its own data out of the contrat 

In addition to the above, one or more composed data objects 1226 are also provided. In particular, each 
composed data object is made to understand multiple different resources. That is the data object can include, for 
instance. SQL statements, as well as CICS and IMS calls, or it can delegate down to. for example, a specific 
DB2 sub data object. 

In one cmbodhnent. m oider to create a composed data object, an initialize method is driven by the 
container. During dus initialization, one or more request helper objects, buUt by the comiection objects, are 

handed to the data object. Each request helper object contains information the data object may need to sustain a 
request toaparticular resound manager. Thus, the container handsalistofhelper objects to the data object and 

the data object selects those diat are needed (e.g., one for DB2, one for CICS, one for IMS. etc.). In the helper 
object is the name of the appropriate connection specification. 
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Described in detail above are server instances, which are used to manage objects located within those 
server instances. In one aspect of the present invention, a server instance can be replicated either on tfie same 
system image or across multiple system images. One example of server instances replicated across multiple 
system images is described with reference to FIG. 13a. 

Depicted in FIG. 13a are two server systems, SYSTEM 1 (1300a) and SYSTEM 2 (1300b) coupled to 
one another, via a couphng facility 1302, to form a clustered syspiex configuration. Coupling fecility 1302 
(a.k.a., a structured external storage (SES) processor) contains storage accessible by the systems and performs 
operations requested by programs in the systems. Aspects of the operation of a coupling fecility are described in 
detail in such references as Elko et al, U.S. Patent No. 5,3 1 7,739 entitled "Method And Apparatus For Coupling 
Data Processing Systems", issued May 31, 1994; Elko et al., U.S. Patent No. 5,561,S09, entitled "In A 
Multiprocessing System Having A Coupling Facility, Communicating Messages Between The Processors And 
The Coupling Facility And Either A Synchronous Operation Or An Asynchronous Operation", issued October 1, 
1996; Elko et al,, US. Patent No. 5, 706,432, entitled "Mechanism For Receiving Messages At A Coupling 
Facility^, issued Januaiy 6, 1998; and die patents and applications referred to therein. 

Each system is executing an operating system image 1304a, 1304b, respectively, such as the OS/390 or 
MVS operating system offered by International Business Machines Corporation (Armonk, NY). As one 
example, operating system 1304a controls execution of one or more server instances 1306a, which arc replicated 
across the system as servers 1306b, For example. Server 1 of System 1 is replicated in System 2 as Server 1. 

Additionally, each operating system includes or is coupled to a workload manager 1308a, 1308b, 
respectively. Each woridoad manager balances workload among the systems of die syspiex in order to achieve 
optimal load balancing and system performance. One example of a workload manager is described in '*OS/390 
MVS Planning: Workload Management," IBM Pub. No. GC28-I761-07 (March 1999), and "OS/390 MVS 
Programming: Workload Management Services," IBM Pub. No. GC28-i773-06 (March 1999), 

Further, coupled to each operating system image is one or more resource managers 1310a, 13 10b, 
respectively. Each resource manager owns and controls the data associated with that manager, as described 
above. " . 

One or more clients 1312 send requests to the server instances via, for instance, TCP/IP connections. 

In order to select an appropriate server instance to perform a task, when that server instance has been 
replicated within a given system and/or across systems in a syspiex, one or more daemons are used, in 
accordance widi one aspect of the present invention. In one example, a daemon 1314a. 1314b (FIG. 13b), 
respectively, has been added to each system. These daemons are location service agents, \iliich are used to 
balance workload, as described below. In particular, the location service daemons facilitate workload balancing 
of client communication sessions to replicated object server instances based on the industry standardized 
CORBA HOP (TCP/IP) protocol widi no proprietary extensions being required either in the communications 
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protocol (e.g.. HOP) or in the client-side nintSmes esablishing communication with the workload managed 



server instance. 



Within the HOP protocol, tiiere exists an architected control flow that occurs «*en a client atten^ts to 
locate an object of interest in a distributed nctwoik This control flow is defined by CORBA and is refiawd to 
as the "locate flow". Tbetc are tbice posable refuses to Ais flow. The flow occurs to flie server instance 
identified by the object reference used to identify the object, and fte server instance responds with: 1) flie object 
is here on tiie target server instance, 2) the object does not exist, or 3) die object is not here on Ae server 
instance, but it may be on another server identified by the new object reference being returned with this 
response. TWs third type of response is called a "location foiward" reply. The client ORB on receiving the 
location forward type of reply issues another locate request to fte server instance identified by die returned 
object reference. 

In accordance with one aspect of the present invention, Ae location fi)iwarding mechanism is used in a 
unique way to cause Ac balancing of client commuiMation endpoints across a set of replicated server instances, 
•me mechanism uses, fi>r instance, direct and indirect object references. A direct object reference is one in 
which Ae acwal network address of Ae subject server process (address space) is bound. An indirect object 
reference is one in which Ae netwoik address of a location service a^t or daemon is bound. It is assumed fisr 
this aspect of tbe present invention that first class refaences to distributed objects are indirect Tlnis, any 
reference obtained by a distributed cUent «q>plication is indirect and results in a locate request to Ae location 
service daemon when it is used. 

One embodiment of Ae logic used to select an appropriate server instance to perfonn a task b described 
wiA reference to FIG. 14. Initially. Ae client obtains an indirect object refetence via, for instance, a name 
service or as a result of an unrelated object meAod request returning the refisrence as an output parameter. STEP 
1400. Then, the client issues a locate request to Ae daemon using Ae indirect object reference. STEP 1402. 

Thereafter, Ae daemon, masquerading as an actual object server instance, consults wiA Ae workload 
manager on its system and asks Ae workload manager to choose an available server instance nmning 
somewhere in the sysplex, so Aat Ais client communication can be established, STEP 1404. The workload 
manager selects a server mstance based on its assessment of available resources and capacity across Ae 
configuration and returns Ae reference information of the selected server instance (e.g.. Server 1 of System 1 or 
Server 1 of System 2) to Ae daemon. The daemon Aen replies to Ae locate request wiA the location forward 
reply passing Ae new reference of Ae actual server instance Aat has been selected. STEP 1406. This returned 
reference is a direct reference so Aat Ae next locate request, by Ae chent. is delivered to Ae acftial selected 
server instance raAer Aan to Ae daemon. STEP 1408. In this case, Ae selected server instance responds to Ae 
locate request wiA "an object is here" reply. 

In order for Ae location service agent to be able to have Ae workload manager select Ae ^propriatt 
server instance to perform a task, the agent first registers itself wiA the workload manager as a daemon. This 
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has specific meaning to the workload manager. In particular, the workload manager expects the daemon to 
come back to the workload manager to request the workload manager to locate a particular environment name. 

In order to register with the woikload manager, the daemon uses various workload management 
inter&ces to obtain die best location of a server instance that has registered with the woridoad manager. It is the 
server instance (e.g., a control region, as described below) that registers with WLM as a "work manager." The 
daemon asks WLM to find an appropriate '*work manager^ under a given class of name, and WLM returns the 
location. 

The use of replicated server instances is optimal when all of die server instances have equal and shared 
access to the resources required by the applicadon server instance. Two specific advantages realized when this 
replication is enabled are 1) reduction of single points of feilure, 2) balanced performance and scalability. 
Further, the 390 system design asserts that the optimal place to make workload management decisions regarding 
the placement of inbound work over a set of replicated server instances is at the sysplex facility where all 
pertinent information required for making an intelligent decision of the placement of the workload exists and 
can be evaluated in real time as the work arrives to the configuration. In addition, in a distributed system, where 
communication protocols and die runtimes implementing those protocols are standardized to allow die 
communication to occur across a set of clients and servers provided by different vendors, there is an advantage 
in making workload management decisions at die server side of die communication runtime so that proprietary 
workload management based extensions are not required in the. various client side runtimes provided by all of 
the various vendors. 

In accordance with another aspect of the present invention, workload balancing across a set of 
replicated servers is performed such that it occurs at well known boundaries widiin the execution of an 
application. This is to protect transient state associated with a running application. In particular, within most 
application server instances, there exists transient state associated with a running application which is tied to aind 
managed from the physical address space or server structure servicing the application. This transient application 
state in such systems is deemed to be valid and coherent within some prescribed and well known unit of 
application activity, such as within a transactional unit of work. Examples of such a state include, but are not 
limited to, updates that have been made to objects or data resident in the virtual memory cache of the address 
space and are pending with respect to the persistent home of the data on some physical medium, such as disk. 
Typically, such pending updates are pushed to their eventual home on disk at the end of the prescribed unit of 
application activity; for example, at the end of the cunent transactional unit of woric. Other examples of 
transient state include control information or meta data used to govern the execution of the application, such as 
state/transition policy or state data reflecting the current state of resources being used by the application, such as 
an open file or communication device. 

Within a distributed system, and within a prescribed unit of application activity, there may be several * 
interactions fi'om a given client either directly to a target server instance where such application state is being 
held, or through multiple other intermediate middle tier server instances to the target server. All requests to the 
target server's application state under a given application unit of activity is directed to the same physical instance 
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of the server's address space in order to ensure proper execution of the distributed application. If, however, the 
tai^et server instance is repHcated across the physical systems in a clustered configuration, and access to the 
replicated server instances is governed by workload management policy, sessions from intermediate nodes in the 
distributed network, established to the target server instance under a common unit of application activity may be 
balanced or spread to different physical server instances, thereby introducing errant behavior in die appUcation. 
In other words, workload balancing across a set of replicated servers is to occur at well known boundaries within 
the execution of the application. Within those boundaries, a mechanism is used to ensure a temporary affinity to 
a specific server instance witiiin a clustered system configuration is defined, recognized and enforced, so that 
any requests under the same unit of application activity from any node in tiie distributed network arrives at the 
saime physical server instance in the configuration. 

To ensure a given transactional unit of work arrives at the appropriate server instance within a clustered 
system configuration, a high performance multisystem registration of transaction interest and the CORE A 
compliant nop related location forwarding mechanism arc used 

One embodiment of ensuring a given unit of work anives at an appropriate server instance is described 
widi reference to FIG. 15. When a metiiod request arrives at a server instance, and it is accompanied by a 
particular unit of woric, such as a distributed transactional context, STEP 1500. a determination is made, by die 
ORB, as to whetiier the server instance receiving tiie request is the owner of the transaction, INQUIRY 1 502, In 
other wc^ds, the server instance makes a local decision as to whether it ahneady owns responsibiUty for the 
inbound transaction. In one example, this determination is made by checking a registration table located witiiin 
the coupling fecility coupled to die server instance or witiiin memory of tiie server instance. 

Should die server instance own responsibility for the inbound transaction, then the server instance 
handles the request. 

If die server instance determines tiiat it is not die registered owner of the transaction, it attempts to 
register die server's interest in tiie inbound transaction, STEP 1504. This registration occurs, for example, at die 
coupling facility and is performed in an atomic fashion by using, for example, a Global Resource Serialization 
(GRS) global enqueue (ENQ). GRS is described in "OS/390 MVS Planning: Global Resource Serialization," 
IBM Pub. No. GC28-1759-04 (March 1998); "OS/390 MVS Programming: Audiorized Assembler Services 
Guide," IBM Pub, No. GC28-1763-06 (March 1999); "OS/390 MVS Programming: Audiorized Assembler 
Services Reference," IBM Pub. Nos. 0028-1764-05 (Sept. 1998), GC28-1765-07 (March 1999), 0028-1766-05 
(March 1999), and GC28-1767-06 (Dec. 1998); "OS/390 MVS Programming: Assembler Services Guide," IBM 
Pub. No. GC28- 1762-0 1 (Sept. 1996) and "OS/390 MVS Progranuning: Assembler Services Reference," IBM 
Pub. No. GC28- 1910-1 (Sept. 1996). The registration information includes, for instance, specified user data 
(e.g., a UUID) in die request, which identifies die specific server instance widiin die configuration associated 
with the specified nansaction. 
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Thereafter, a determination is made as to whether the registration was successful, INQUIRY 1506. 
That is, if no other server instance replica has registered its interest in the same transaction, then registration 
succeeds and that server is deemed the appropriate server instance for the unit of work, STEP 1508. If some 
other server instance replica has registered its interest in the transactioii, the attempt to register &il$. In this case, 
a GRS operation (e.g., a GQSCAN) is initiated to obtain the registration information, which inchides the xdentiQ^ 
of the server instance that is registered for the transaction and the transaction id, STEP 1510. When that 
information is returned, a new object reference is buiit using the location of the registered server instance and 
the cunent object key for the object being dispatched, STEP 1512. 

Subsequently, the server instance returns a location forwarding reply to the client, STEP 15 14. The 
CORBA protocol allows the location forwarding reply to be returned on any distributed method lequest sent to a 
given server. The client ORB then uses the new object reference to establish an HOP connection to the 
appropriate server instance within die sysplex, STEP 1516. 

By using the above protocol, advantageously, iif a connection fails while a transaction is being 
processed, the connection can be reestabhshed without aborting the transaction. 

As described above, the ORB provides low-level connectivity capabilities that allow objects relate to 
one another. However, in order to enable applications and odier components to be written in ORB-based 
environments, other functionalities are provided. According to.the Object Management Group (OMG), these 
functionalities are to be defined as separate modular components above the ORB level. One of these 
functionalities includes a naming service, which allows objects to refer to other objects by name. In particular, 
die OMG Naming Service allows human readable names to be assigned to objects, so that the names can be later 
used to find the objects. 

Names exist and are unique within a naming context Specifically, a name is bound to an object within 
a naming context (i.e., a binding). A naming context is itself an object, and thus, it can be bound with a name to 
one or more othernaming contexts. 

The OMG Naming Service specification (based on CORBA) defines a system name space and a set of 
operators that can manipulate die contents of that name space. One example of a name space is depicted in FIG. 
16a and described herein. A name space 1600 includes a plurality of objects 1602, referred to as naming context 
objects or naming contexts. Each naming context object includes at least one binding to another object. That 
binding maps a human readable name to an object reference which identifies die named object 

A fundamental concept in the OMG Naming Service is that the name space is composed of naming 
contexts bound together to form a tree 1604. Since each naming context is itself an object, and thus, may be 
distributed, the name space may be distributed across multiple name servers across the distributed network. (As 
anodier example, the name space is not distributed (see FIG. 1 6b)). 



30 



Creating an association between two naming contexts is simply a matter of binding or associating the 
one context with a name into the other context, just like any other object To be more specific, the name service 
provides two distinct interfaces for associating a name with an object. One is used to bind naming contexts to a 
parent naming context, and the other is used to bind non-naming context objects to a parent naming context. 

•5 

To further illustrate the structure of the name space and the placement of naming contexts widiin the 
stnicmre, refer to FIG. 17. HG. 17 depicts one example of a hierarchy of naming contexts 1700 within a name 
tree 1702. Note that the objects themselves do not have names. Instead their bindings 1704 have Ae names 
(e.g.. A, B, ...). Therefore, an object name is by natore contextual and relative based on its placement within the 
10 tree. The name bound to the object exists within a given naming context 

One problem associated with conventional naming services is how to map bindings and naming 
contexts onto particular data models, such as the data model provided by the Lightweight Directoiy Access 
Protocol (LDAP)/X.500. (The LDAP protocol and the X JOG data model are industry standards provided by the 

15 XOPEN Group. Standaids for X.500 include CCm X.500 standards described in ITU Recommendations 

X.500-X.520; LDAP is described in IETF RFCs 225 1-2256.) In particular, a need exists for such a mapping that 
is performed in a way that fully utilizes the semantics and stxucttire of the underlying directory without resulting 
in an implementation that is intimately linked with the underlying directory technology. 

in accordance with one aspect of Ae present invention, a solution to Ac above problem is provided that 

2 0 leverages the abstractions made available via object technology, along with the abstractions provided by 

component broker runtime services. The solution allows naming contexts and named bindmgs (described 
below) to be retrieved via a "single hop" even when the names are compound names. Single hop retrieval means 
that a resolve method, such as the CosNaming::NamingContext::resolve method, can locate the desired object 
with a single lookup to the underlying directory (e.g., the LDAP directoiy), as oj^sed to multiple lookups or 

2 5 multiple internal calls to resolve. 

In addition to the above, this aspect of the present invention further improves performance by allowing 
naming contexts and named bindings to be handled in a consistent feshion. thereby reducing the number of local 
search queries required. Lastly, the implementation provides a structore tfrnt physically separates algoritimis 

3 0 from specifics of die underlying directory technology. 

In particular, in one embodiment, object specialization is employed, which allows objects m tiie name 
space to be treated as bindings. That is, a binding falls into one of three categories: a named bindmg used to 
rq>resent a binding to an application object; a disjunction which represents points of discontinuity in die name 
3 5 space, as described furtiier below; or a naming context that represents a naming context specialization. 

Both die naming context and binding classes are managed objects. As managed objects, they are 
broken down into a business object and a data object. The naming context business object includes die 
algorithms that manipulate an abstraction of the directory (e.g., LDAP). while die data object is responsible for 
40 managing the relationship with the underiying directory. One example of die inheritance and delegation 
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relationships associated with the componeats of a managed object are depicted in FIG. 18* For instance, it is 
shown that NamingService::NamingContext inherits torn both lextendedNamingiiNamingContext and 
NamingService::Binding. 

The data object uses the services of the underlying directory to create, delete, retrieve, and update 
entries that correspond to bindings and naming contexts. In accordance with one aspect of the present invention, 
the binding and naming context classes support the same attributes. Thus, the binding and naming contexts 
classes act as dual personalities for the same underiying directory data. A personality is defined as the object 
representation of die data. Since a naming context is a binding because of the inheritance relationship between 
them, the existence of that binding implies the existence of the naming context bound in Che name space. 

Defining the naming context in this manner allows efficient one hop lookup of objects that reside in a 
particular name server. Since each object that is included in the name space is represented by a binding object, 
the retrieval of a named binding of a given name requires a search against a single home collection — the 
binding home collection. 

Each binding contains an attribute that represents the handle for its associated personality. In die case 
of bindings that r^iescnt naming contnts, the personality is a pointer to the object whose class is naming 
context, but whose primary key is the same as die binding, namely it is the fiiU binding name. Thus, once the 
desired binding has been located, the view of the data backing diat binding is transformed to the naming context 
class by returning the personality attribute. Thus, the dual personality of the same directory data is seen. 

Furthermore, if the binding, represents a binding to an application object, the personality attribute is 
used to store a reference to the boimd object Thus, resolution of named bindings can be performed through a 
search on the binding home collection. The object that is bound to that named binding is contained in the 
personality field. In the case of bindings that represent naming contexts, the personality field contains a 
reference to an object of type naming context that is backed by the same data. This dual mapping is made 
possible, since each of the references to each of these objects contains the same key into the director^'. This is 
described in further detail below. (In at least some of the pseudo-code described herein, only excerpts of the 
code are given, which are relevant to the surrounding discussion.) 

One example of pseudo-code associated widi an implementation of bind_new_context, which is used to 
create a new naming context and bind it into the name space is provided below. (In at least some of the 
pseudo-code described herein, only exceipts of die code are given, which are relevant to the surrounding 
discussion.) 

NamingContext bhid_new_context (hi Name name) 
raises (NotFound, 

CannotProceed, 
InvalidName, 
AlreadyBound); 
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- If name is a compund name then 

- ctx - executing naming context -> resolve 
(<cl;c2;.,.cn-I>) to find the naming 

context to which the new context will be 
bound. 

- Invoke ctx->bind_new_context(<cn>) to 
invoke the bind_new_context on 

a simple name. 

- Return 

- Else name is a simple name 

" Buildtheprimaiy key string for the new 
NamingContext object to be created. 

- Drive the constructor on the 
NamingContext home collection 
(createFromPrimaiyKeyString) using fliis 

key. 

- Set die binding type attribute to Naming 

Context 

- Save the lOR for diis new NamingContext 

in Ae personality atrribute. 

- Remm die NamingCoritext object 

The above procedure for bind_new_context creates a new object on a single home collection (e.g., the 
Naming Context home collection). By definition, the binding object is created at the same time because of the 
inherifance relationship. Thus, the creation of a naming context and the binding of die context into die name 
space are synonymous. Also note that diis procedure first calls resolve so diat it can operate on a simple name. 
In die above pseudo-code, invoke ctx->bindjiew_contcxt is a recursive call. At some point, a simple name is 
provided, and die logic dien continues widi die build of die primary key string. When all naming contexts 
associated widi die compound name, as well as die object upon which bind_new_context is invoked, exist in die 
same name server, the new naming context object can be created widi only a single hop to the resolve mediod. 

Application objects aie bound into die name space using die bind mediod. The following procedure 
describes one embodiment of die bind method. Note diat the bind mediod can create a new named binding in a 
single hop while requiring only a single create operation: 

void bind (in Name name. In Object obj) 
raises (NotFound, 

CannotProceed, 

InvalidName* 

AlreadyBound); 

- If name is a compound name then 

-ctx = executing naming context -> resolve 
(<cl;c2;...cn-l>)tofmd 
the target naming context to which the 
object will be bound. 

- Note that die resolve operation will throw 
an exception if the 

specified name could not be found. 

- Invoke ctx ->bind (<cn>, obj) to invoke die 

bind on a simple name. 

- Return 

- Else name is a simple name 

- Build die primaiy key string of die new 
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Binding object 
- Drive the Binding home factory by calling 
createFromPrimaryKeyString and passing the 
PrimaiyKey. 

- if the name already exists in Binding 
home collection. 

- Throw AlreadyBound exception. 

- else a new Binding object was created 

- Set the personality attribute in the 

new Binding object to obj. 
. Set die binding type attribute to bound 
object 
- Return 



In die above logic, a createFromPiimaiyKeyString method is called. This operation is, for instance, a 
factory method on the home collection used to create the new persistent object of the type i^ident in that 
collection. It is the mechanism used to create persistent managed objects in the system. 

At this point, new named bindings have been added to die name space. The mapping of these named 
bindings to the underlying directory allows for efficient retrieval with the resolve method. Only the home 
collection for bindings need be searched and the contents of the personality attribute of die retrieved binding 
returned. This works whether the binding represents a naming context or a bound application object 

One example of the procedure for resolve is as follows: 



Object resolve (in Name name) 
raises (NotFound» 

CannotProceed, 

InvalidName); 

If the input name begins with '/* or \* then 

-Invoke resolve_initial references to obtain 

the Naming Service Root. 
-Redrive die resolve on the root naming 
context passing the remainder of the name. 
-Return 

- Create the primary key string representing the 
objiect in the Name Space to be found. 

- Drive findByPrimaryKeyString on the Binding home 

collection passing the primary key string. 
- If the Binding object was found dien 
- Return die bound_object attribute of 
the Binding object. This may eidier 
be a leaf node object or a 
NamingContext object. 

Described in detail above is a capability fhzt allows a new named binding to be created in a single hop, 
as well as allows multiple level names to be resolved in a single hop from the root naming context. This means 
that create and resolve, respectively, need to be called only once, when starting from the root. Additionally, a 
single repository (LDAP) is used as die persistent store for bodi the naming contexts and bindings. Further, die 
state of a binding is typed in order to indicate the type of binding. 
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AS described above, in constructing the name space, it is possible that portions of the name space may 
exist in different physical systems. TTiat is, one server may be on one system, while another server may be on 
another system. For example, with reference to FIG. 17, Naming Context /B% may exist on System A, while 
Naming Context JB/D% may exist on System B. The underlying lesource managers for these naming contexts 
may not be the same (e.g., they may have differem data schemas and formats in the database, different protocols 
used to navigate the directory schema, and/or different formats of the names used to represent the entries in the 
directory system, etc.). For example, naming context JB% may be stored in LDAP. and Naming Context 
JB/D% may be stored in DCE CDS (Distributed Computer Environment CeU Directory Services). A schematic 
illustration of this scenario is depicted in FIG. 19, in which a Naming Context JB% 1900 is located in Name 
Server 1 (1902) of System A and is backed by an LDAP resource manager 1904; and Naming Context ,/B/D% 
1906 is located in Name Server 1 (1908) of System B and its data is backed by a DCE CDS resource manager 
1910. 

Since the naming contexts reside on different systems, there are said to be "foreign junctions" within 
the name space. Tliat is. a particular naming context (c.g., JBfD%) cannot be resolved on one system, and thus, 
foreign junctions exist. In accordance with one aspect of the present invention, such foreign junctions are 
traversed in a manner that does not compromise performance and is not dependent on knowledge of the 
underlying directory technology used. 

As described in further detail below, the technique used by this aspect of the present invention 
leverages the abstraction provided by die object representation of the underlying naming context storage 
mechanism and introduces the concept of disjunct bindings. Disjunct bmdings represent locations in the 
CORBA name of the naming context where a deviation occurs from the nattiral name resolution capability of the 
underlying directory technology. For example, the OMG name service binding name might be a/b. The "a" part 
of the name might be mapped to directory System X, where the actual name in die underlying directory is of the 
format "name = a". Hie "b" part of the name might be resident in a different underlying directory. Directory Y. 
where the underlying directory name of the element might be "partname The junction benveen a and b is 
a large junction over two different directory systems with two different naming schema that needs to be 
federated to forai the "a^" named binding in the object space. Identification of diese disjunction points allows 
foreign junctions to be identified efficiently and easily. 

In addition to the above, this aspect of the present invention makes use of the disjunct binding concept 
to implement alias names in a homogeneous manner. An alias name for a naming context is an alternate name 
for that naming context. The naming context is initially bound under a primary name, which becomes its hard 
link. Additional, alternative paths to diat naming context make use of alias names. Alias Names and foreign 
junctions are handled in the same manner. 

Advantageously, alias names and foreign junctions are handled in a way that maximizes the benefits of 
an efficient mapping to the underlying directory technology during the name resolution operation. It does so in 
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such a manner as to maintain independence from the underlying directory technology of the name space 
segments on both the local and foreign systems. 

In one example, the name resolution operation includes a resolve method, which is used to find an 
object associated with a given name. As part of the processing of Ae resolve method, disjunct bindings may be 
encountered. The manner in which diis is handled is described below with reference to FIG. 20. 

In one embodiment, a primary key is constructed based on the input name, STEP 2000. The primary 
key may represent an object several layers down in the name space. One example of constructing die key is 
described below with reference to FIG. 22. Subsequent to constructing the primary key, a findByPrimaryKey 
method is called to search for the name space object known by that primary key, STEP 2002. As one example, 
the findByPrimaiyKey operation is inmxluced on die home collection and can be used to query die home 
collection for the managed object designated by die input primaiy key value. 

If the find is successfixl. INQUIRY 2004, then die desired binding is found. Thus, die object associated 
widi that binding is returned to the caller, STEP 2006. This object may eidier be an application object or a 
naming context. Thus, a multiple level resolution may be perfonned in a siiigle stqi, as described herein. 

If die findByPrimaiyKey cannot find die target object, then die findByPrimaryKey is driven on die 
largest portion of the name that could have potentially been resolved, STEP 2008. This can be achieved by 
incrementally backing oflF the rightmost name component until die findByPrimaiyKey is successful or die entire 
name has been consumed. Alternatively, die underlying directory technology may sapply the portion of the 
name which could have been resolved after die first findByPrimaryKey was unsuccessful. This information 
could be provided to the business object in a general way such as through an exception. 

Should no portion of die name be located via findByPrimaiyKey, INQUIRY 2010, a NotFound 
exception is provided, STEP 2012. If, on die odier hand, a portion of die name is located via 
findByPrimaiyKeyString, a disjunction has been located in die name space, STEP 2014. This disjunction may 
eidier represent a foreign binding or an alias name. The object associated widi diat binding is retrieved and die 
resolve mediod is re-driven on diat object using die remainder of the object name, STEP 2016. (If die 
disjunction represents a foreign binding, dien the resolve mediod is redriven on a different system. This system 
can have a different implementation of the CORBA architecmre dian die system in which die disjunction is 
located.) Thus, performance has been maintained in die case of a usual look-up, widi disjunctions handled m a 
straightforward and homogeneous maimer insulated torn the mechanics of the underiying directoiy. 

Further details associated widi die resolve mediod are described below. In particular, one embodiment 
of the logic associated with resolve is as follows: 

Object resolve (in Name name) 
raises (NotFound, 
CannotProceed« 
InvalidName); 
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If the input name begins with T or 'V then 

- Invoke resolve_mitial_references to obtain 

the Naming Service root 

- Redrive the resolve on the root naming 

context passing the remainder of the name. 

- Return 

- Create the primary key string representing the 

object in the Name Space to be Foimd. 

- Drive findByPrimaryKeyString on the Binding home 

collection passmg the primary key string. 

- If the Binding object was found thesi 

- Return the bound_object attribute of the 
Binding object.. This may either be a 
leaf node object or a NamingContext 
object. 

- Else the findByPrimaryKey method did not find a 
Binding object. 

- Find the largest n such that a 

findByPrimaryKey on the Binding home 
collection using the primary key for name 
=<cl;c2;...,cn> is successful. 
• If the Binding for such an n could be found 
then 

. Obtain the bound-object attribute from 
the Binding object. This represents a 
NamingContext object. 

- Drive resolve on this NamingContext using 

name ==<cn+ 1 ;cn+2,...,cz> where cz is the 
last component in the original name. 

- Return the object reference returned from 

the resolve invocation. 

- Else no Binding could be found 
-Throw a NotFound exception. 



As can be seen above, the approach described herein has no direct infractions with the backing 
directory on either die local or foreign system; it solely makes use of cUrait-side interfaces that are defined to th< 
object space of the component broker programming model Specific use is made of the instance management 
ihterfeces, as well as Aose supplied by the Naming Service and potentially any "hint" (i,e.. matched portion of 
the name) of the largest sub-portion of the name that can be resolved in one hop. 

The disjunct binding was originally established as a result of a bind_context invocation. One example 
of the logic associated with a bind_context is as follows: 



void bind_CDntext (in Name name, m NamingContext nc) 
raises (NotFound, 
CannotProceed, 
InvalidName 
AJreadyBound); 

- If name is a compound name then 

- ctx = executing naming context -> resolve 
(<cl;c2;...cn-l>) to find the target naming 
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context to which the input context will be 
bound. 

- Invoke ctx->bind_contexi (<cn>. no) to 

invoke the bind^context on a simple name. 

- Return 

- Else name is a simple name 

- Build the primary key string of the new 

Binding. 

- Drive the Binding home factory by calling 

create FromPrimaryKeySring and passing 
PrimaiyKey. 

- If the NamingContext already exists 

♦ Return the AJreadyBound exception. 

- Set the binding type (bt) attribute of 

the new Binding to ndcontext to indicate 
that this Binding object represents a 
disjimct binding. 

- Set the t>ound_object attribute to the 

input naming context nc. 

- Return 

Described above is a technique for handling foreign naming contexts. Advantageously, multiple level 
names that include junctions to a foreign naming context or alias can be resolved widi a minifmim number of 
hops. 

In one aspect of the present invention, in order to facilitate efficient one hop name resolution, the 
contextually sensitive CORBA Name (i.e., CosNaming::Name) of an object is mapped to that object's identity 
(e.g., its primary key) and then, to an LDAP X.500 (as one example) distinguished name in a manner that is 
efficient, but also maintains separation between the CORBA object domain and the directory domain. 

In particular, in one example, the CORBA name relative to die root of the server in which the object 
resides is used as the object primary key of the name space object (e.g., binding or naming context). The object 
primary key is then used to determine the distinguished name of the directory entry diat represents die object 
Thus, the identity of die name space object is intimately tied with its name relative to the root of the name space 
of the server where the object resides. The advantage of diis approach is that it &cilitates efficient one hop name 
resolution, reduces the need for indirection, and eliminates the need to store CORBA names as binding 
attributes. 



One embodiment of the logic associated with mapping a CORBA name to a distinguished name to 
dispatch a method on the named object is described with references to FIG. 21. As one example, when a method 
is invoked on a name space object, a method request flows from a client (i.e., an invoker) to the name server, 
STEP 2 100. Included in this flow is a reference (lOR) to the object on which the method is to be invoked (this 
object is referred to as the executing object). The reference includes the object key of that target object. The 
ORB extracts the object key out of the lOR and provides it to the container, STEP 2102. As part of the object 
instantiation process, tiie container creates a naming context data object and provides it with this key. STEP 
2104. (As described above, the data object is responsible for the interactions with the directory.) 
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Subsequently, die data object extracts the CORBA name torn the key, STEP 2106. For example, an 
object key may have a format of "root container/binding home primary key/object primary key'*, where a 
possible value for the object primary key portion is "Y12A.Dept/Jeffirey Frey. Programmer**. The data object 
extracts the object primary key portion of the primary key to obtain a string form of the CORBA name of that 
object relative to the root of the server. With the above example, the string is "/Y12A.Dept/Jeflfrey 
Frey.Programmer". 

The object primary key is then reversed and further manipulated to build an LDAP distinguished name, 
which can be used by LDAP to locate die corresponding directory entry, STEP 2 108. 

The following is one example of the resulting distinguished name using the CORBA Name from the 
previous step. LDAP Root is the location of the name space root in the underlying directory. 

TypelessRDN= Jeffrey Frey.Programmer, 
TypelessRDN=Y12A.Dq)t, TypelessRDN=/,<LDAP Root> 

The data object then uses this distinguished name to retrieve the data in a single operation, STEP 2110. 
Thereafter, the remaining object instantiation processing is performed and die method dispatched, STEP 2112. 

By using the CORBA name as part of die object key, fee object reference (i.e., the Interoperable Object 
Reference) contains die inforaaation needed to retrieve die object from the underlying directory (e.g., LDAP 
X.500). No metastate tables are required to map die object key to die distinguished name. In addition, die 
undalying structure of the directory is representative of die stmcttire of the name space. That is, name space 
objects need not use the directory in a flat manner with all name space objects bound under a single directory 
entry using some generated Name. 

Described above is die instantiation of previously existing name space objects. What is described next 
is die construction of primaiy keys for the creation of new name space objects. As one example, a 
bind_new_context(name) method results in die creation of a new naming context object bound in the name 
space using name "name" relative to the executing naming context. One embodiment of the logic associated 
witii creating a new primary key for new objects is described widi reference to FIG. 22. 

Initially, die primaiy key of die currently executing naming context is obtained, STEP 2200. (This key 
is readily available, since die object exists and has an identity). Thereafter, die primary key is converted to a 
CORBA name. STEP 2202. 

Subsequent to obtaining the CORBA name, die input name "name" is appended to the CORBA name, 
STEP 2204, Thereafter, die resulting CORBA name is converted to an object key. Step 2206. 

For example, assume diat a new naming context under die name "/Yl2A.I>ept/Jef&ey 
Frey.Programmer/Component Broker.Project" is to be created. In order to create the new naming context, die 
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bind_new_context method is called on the.currendy executing naming context, whose name is 
"A'laA.Dept/Jeffrey Frey. Programmer", in this example. The name passed on the bind_new_context call is 
"Component Broker.Project'*. Within this method, a primaiy key is created. 

To create the primary key for die new naming context, die string from of the CORB A name of die 
currently executing naming context is extracted. At die point in die processing diat the new key is being built, 
die primary key of die currently executing naming context is "root container/Binding home primary key/object 
primary key", where die value for die object primary key portion in die example is "/YllA.Dept/Jefifrey 
Frey .Programmer". 

Thereafter, die object primary key is extracted, vMch provides die string form of die CORBA name of 
die object relative to die root of die server. As before, diat string is: -/Y12A,Dcpt/Jefifrey Frcy.Piogiammer". in 
diis example. Then, die name of die new binding relative to die currendy executing naming context is 
concatenated to die CORBA name to yield a CORBA name string of "A^llA.Dept/Jefifrey 
Frey .Programmer/Component Broker.Projecf. This string is dien used as the object key of die primary key of 
die new naming context tiiat is being created, whose form is "root container/Binding home primary Key/object 
primaiy key". As a resuh of diis approach, die structure of die object primary key in die object key contains all 
of die infonnation needed to either coiistruct an LDAP distinguished name or die string form of die CORBA 
name of the object relative to the root of the server. 

A further example of die above is as follows. Assume a tree having a/b/c/d/e/f. Further, assume diat a 
resolve mediod is driven against a naming context designated by die simple name c, and diat die object bound 
relative to die naming context bound at name d/e/f is to be located or created. Thus, the foil identity of die 
naming context at die c position is a/b/c. Its real name in LDAP is, for instance, typelessRDN=c, 
typelessRDN=^, typeRDN=a. This LDAP name is used to retrieve die object associated widi diat name from die 
LDAP directory. The data object converts die LDAP name to its CORBA name, a/b/c, Then,/d/e/f is appended 
to die CORBA name, yielding a/b/c/d/e/f. The entire CORBA name is dien converted to a new object key, as 
described above. At a subsequent point, die new primary' key is provided to a data object, which uses it to build 
a distinguished name. This distinguished name can dien be used to find or create an entry. 

This new key can be used as input to, for instance, a creatcFromPrimaryKeyString mediod to create die 
new naming context object and associate (or bind) it widi die name space. As part of die processing to achieve 
diis, die new key is provided to a data object, who creates die distinguished name and calls ldap_add. 

In die next example, die new key is used to find an existing entry. For example, diis same primary key 
construction approach can be used as part of a resolve mediod to locate an object bound in die name space in a 
single hop. The resolve mediod is implemented in. for example, a naming context business object. (As 
described above, a business object contains die primary application interfaces and algoriduns). During resolve, 
die new key is passed to die fmdByPrimaryKeyString which passes die key to a data object This data object 
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uses the key to buUd the distinguished name and caU Idap.search. One embodiment of a resolve method that 
uses the primary key creation process is described below: 



Object resolve (in Name name) 
raises (NotFound, 
CannotProceed» 
InvalidName); 

If the input name begins with T or V then 

- Invoke resolve_initiaLreferences to obtain 

the Naming Service root. 

- Redrive the resolve on the root naming 

context passing the remainder of the name. 



• Return 

. Create the primary key string representing the 

object in the Name Space to be found by 
concatenating the input Name to the Coiba Name 
represented in the primary key 
of the executing Naming Context. 
. Drive findByPrimaryKeyString on die Binding home 

collection passing the primary key string. 
- If the Binding object was foimd then 

- Return the bound_object attribute of the 
Binding object. This may either be a leaf 
node object or a NamingContext object 



The defining of name space object primary keys in the above manner allows name resolution to be 
performed in a batch fashion. The name that is the target of the search can be resolved in a single hop, even if 
that name represents an object that is several layers down in the directory hierarchy. This approach allows the 
underlying semantics and performance characteristics of the underlying directory technology be ocploited. 

In accordance with one aspect of Oie present invention, multiple updates to the name space are made 
atomically with one another, as well as with the creation and update of appUcation objects. For example, an 
application object, such as an insurance policy object, is atomically created and bound into the name space. This 
maintains the overall integrity of the name space. In one embodiment, atomic updates are provided by the 
addition of transactional semantics in the name server. Transactional semantics for name space objects are 
achieved by making name space objects managed objects. As managed objects, they inherit a set of qualities of 
semce that include the transactional characteristics. In conjunction with this, a local interface to a directory 
service is supplied that propagates a transactional context from the name server through, for instance, the LDAP 
directory and finally to die resource manager. 

To achieve transactional semantics on name space objects, multiple components of a computing 
environment are used. These components include, for instance, an underlying resource recovery service (RRS) 
2300 (FIG. 23), which serves as a generalized two-phase commit manager, an object transaction service 2301. 
which is coupled to and worics with RRS; a rx^source manager 2302 (e.g.. a database subsystem), which exploits 
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the RRS protocols; LDAP services 2304, which exploits the RRS protocols to create a local backend 2305, 
which is coupled to resource manager 2302; and a server infrastructure 2306. including an object request broker 
2308 and a container 23 12. 

These components are brought together by the name server through use of the component broker 
managed object framework as the programming model and dte use of the LDAP local backend as the directoiy 
service used as the backing store for naming objects. 

By using the managed object framework, the name server supports a set of architected inter&ces diat 
allows the container to manage the transaction. These interfaces include those used for tiie business object, 
which includes the application logic for implementing the client level interfaces; and the data object, which is 
re^nsible for interactions with the backing store, in this case, the LDAP local backend. 

The LDAP local backend allows the LDAP server functions to execute under the same unit of work that 
invoked the associated LDAP client function. By doing so, RRS context infomiation can be propagated from 
the name server, across LDAP, and into, for instance, the DB2 database. Further details of LDAP local backend 
2305 are described below. 

In particular, in accordance with one aspect of the present invention, the LDAP server code is allowed 
to nin locally to the LDAP client code. Thus, the client code and server code are packaged together with 
modifications that allow the network flows to be by-passed. 

For example, the ORB establishes a transactional context. Thereafter, the naming data object receives 
control and invokes LDAP interfrices» such as LDAP client interface code and LDAP server code (which reside 
on the same server). Then, DB2, for instance, retrieves die transactional context. 

In this arrangement, a caller such as the naming data object calls the LDAP client interfrice code. The 
client interface code then directly calls the LDAP server code without going outbound on the network. Thus, the 
naming data object, the LDAP client code, the LDAP server code, and the invocation to DB2 end up running 
under the same unit of work. DB2 is therefore able to access the transactional context that was established by 
the ORB prior to the LDAP client code being invoked. (LDAP is fiirtfaer described in "LDAP Server 
Administration and Usage Guide." IBM Publication No. SC24-5861-00 (Jan. 1998), and at DS.INTERNIC.NET 
RFC 1777.) 

Certain details of how a transactional name server is defined and operated is described below with 
reference to various logic flows. As one example, the control flow associated wi± creating an object in a 
transactional enviroimient is described with reference to FIG. 24. This example is from the perspective of a 
naming object (e.g., a naming context or a binding). Further, in this example, a new naming context object is 
being created through the bind_new_context method described herein. 



42 



Initially.atnmsactionbegim. When, for instance,acUentperf^^ 
STEP 2400. Tlie container is activated and the transaction context is atmched to the thr As 
part of the container activation, two connection objects are initialized. One sets up the connection with, for 
instance, an LX)AP resources manager by calling ldap_open and ldap_bind. As a result of these calls, a handle is 
provided that will be used by the data object for its funire intciactions with LDAP. The second connection 
objec. that is initialized is die one for RRSAF. which proceeds, as previously described herein. Through this, 
the enviionment is set up that allows interactions with the name server to be perfonned under a transactional 
scope. DB2 can pick up the transactional context that the ORB attached to the thread of execution. LDAP 
manages the DB2 data per the requests made by the naming context data object Once all of this is set up. the 
bind-new-comext method is dispatched on the currently executing naming context It buUds an object key for 
Ae new naming context, as previously described herein. It then invokes createByPrimaryKeyString against the 
Naming Context home to cause the new object to be created. As part of this processing, the new data object is 
created. STEP 2402. 

Additionally, a business object is created and associated with the data object, STEP 2404. As one 
example, the association is performed by calling inltForCreation. Defimlt attributes are copied fiom the data 
object to the business object 

Subsequent to creating the data and business objects, the transaction is committed, STEP 2406. During 
the commit, an inseitToDataStore method is called on the data object, which causes a new directoiy entry (e.g., 
an LDAP directoiy record) associated with the intemaliTed key to be created, STEP 2408. In particular, when 
the transaction is committed, the insertToDataStore invokes the services of the LDAP directory service to create 
the new directoiy entiy. That is an ldap_add, in this example. LDAP pcrfomis the appropriate manipulations of 
the underiying DB2 database in order to create the entry. Because the data object, LDAP. and eventual DB2 
calls are all rumiing under die same thread of execution, and therefore, under the same transactional context, this 
modification to the name space is associated widi a specific transaction. 

After creating an object, the object can be retrieved. Some of the control flow associated with 
retrieving an existing object is similar to the flow for creating an object, and d,us. reference is made to the above 
discussion, as well as to the same figure. HG. 24. In one example, the retrieve flow takes place as part of 
activating an existing naming context. 

Initially, a transacUon begins, STEP 2400. A data objea is created, STEP 2402, as well as the business 
object, as described above. The business object is associated with die data object, STEP 2404. In this insunce, 
the business object is associated with the data object by calling initForReactivatfen. 

Thereafter, the data is retrieved. In this instance, retrieveFroraDataStore is called on die data object 
which causes the data object to drive an ldap_search. and LDAP. in mm. interacts widi DB2 to obtain the data. 
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Once the object is retrieved, it can be updated. For example, an update may be that a bind modified a 
binding to point to a difTerent apphcation object One embodiment of the control flow associated with updating 
an object once it has been inserted or retrieved is described with reference to FIG. 25. The scenario for update is 
similar to those described above. 

Initially, a client (i.e., an invoker) updates one or more attributes of the business object, STEP 2500. 
Thereafter, the transaction commits, STEP 2502. As part of the commit process, pre-prepare causes 
initForPassivation to be called on the business object, diereby flowing the business object attributes to the data 
object, STEP 2504. . . 

Further, during the commit process, the attributes are passed to the LDAP directory using 
updateToDataStore, STEP 2506. UpdateToDataStore invokes LDAP, which in turn, interacts with pB2. For 
example, LDAP stores tkc attributes in a data store of a resource manager, such as DB2, STEP 2508. 

After the attributes are stored, the business object and data object are deletied fipom memory, STEP 
25 10, and DB2 receives a prepare and conunit flow, STEP 25 12. This concludes updating an object in a 
transactional name server. 

One embodiment of the control flow associated with deleting an object, once it has been inserted or 
retrieved is described with reference to FIG. 26. Initially, a client drives a remove method against an object, 
STEP 2600, and the transaction commits, STEP 2602. As part of commit, uninitForDestniction is called on the 
business object in order to delete the object, STEP 2604, Additionally, the LDAP directory entry and associated 
DB2 data is deleted via deleteFromDataStore, which is called on the data object, STEP 2606. In one example, 
the data object uses ldap_delete() to perform the deletion. Further, the business object and data object are 
deleted from memory, STEP 2608, and DB2 receives a prepare and commit flow, STEP 2610. 

In each of the above control flows, there is a transactional context that is flowing. One embodiment of 
how the transactional context flows during the above-described control flows is described with reference to FIG. 
27. 

Initially, a client (i.e., an invoker) creates a transaction and the transaction context flows with its 
interaction with the name server, STEP 2700. That is, the client performs a begin_tran and the transactional 
context flows as part of the method invocation, as described herein. The transaction context is established in the 
name server and associated with the business object and data object pair, STEP 2702. 

Thereafter, the transactional context is retrieved by DB2 for updates to DB2 tables, STEP 2704. DB2 is 
able to retrieve the transactional context by virme of running under the same unit of work that owns the business 
object/data object pair. 



With the capabiUties described above, multiple naming contexts and application objects can be 
manipulated in one or more s»ver instances atomically. Take the following example: 

1 ) Begin a transaction; 

2) Create a naming context A; 

3) Create an q>plication object B; 

4) Create an q>plication object C; 

5 ) Bind application object B under naming context A; 

6) Bind s()pKcation object Cundernamingwmtext A; 

7) Commit or toll back lbs transaction. 

Since the scope of an objecf s life in memory is associated with the scope of the transaction, server 
replication becomes possible. An object that is active within a given server is locked. As such, any replicated 
server cannot access it untQ Aose locks are released. 

Described in detail above is a transactfonal name server that provides for multiple atomic updates to a 
name space. A transactional name server advantageously makes possible server replication which improves 
availability and performance characteristics of the server. In accordance with this aspect of the present 
invention, component broker mechanisms are used in conjunction with a particular implementation of LDAP to 
allow the data object. LDAP and the DB2 calls to run under the same unit of work. Tliis makes modifications to 
the name space transactional. As described above, this could involve retrieving bindings or naming contexts, 
creating new ones, or modifying exbting ones. Tins has lead to various enhancements. For example, when 
initializing the name space, entire segments of the name space can be built under the scope of a single 
transaction. As a result of this, when commit is performed, either all of the changes take place or none of them 
take place. This eliminates the possibility of creating partial name spaces wifli inconsistent states should 
processing terminate prematurely. Furthermore, a transactional name space aflows appUatioa objects to be 
created and their references register«d in die name space under the scope of a single transaction. This avoids 
scenarios where processing is interrupted between object create and name space registration, which would result 
in orphaned objects. 

As described in detail above, a name space is provided, which manages naming context objects. In one 
aspect of the present invention, a name space 2800 (FIG. 28) also includes a repository, such as a Life Cycle 
Repository (LCR) 2802. The Life Cycle Repository is located within, for instance, a private portion of the name 
space, and includes a set of fectories. 
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Factories provide a client (i.e., an invoker» a user) with specialized operations to create and initialize 
new object instances. A GenericFactory interface is defined by the Life Cycle Service. The Life Cycle Service 
is an OMG architected set of services that define conventions for creating, deleting, copying, and moving 
objects. These services allow remote clients to perfonn life cycle operations on objects in different locations. 
The GenericFactory serves as a creation service and provides a generic operation for object creation. To create 
an object in such a way, a client uses an object reference to a factory. The client can obtain the fectory object 
reference through use of the Naming Services or through the use of a Life Cycle FactoryFinder service, 
described below. In addition, clients may be passed factory objects as parameters. 

A client that wishes to delete an object issues a remove operation. To delete an object in such a way, 
that object is to support the LifeCycleObject interface. The LifeCycleObject interfece also supports move and 
copy operations. The move and copy operations are passed an object reference to a FactoryFinder. The client is 
thereby specifying to move or copy the object using a &ctory within the scope of the FactoryFinder. 

FactoryFinders support the find^factories operation, which returns a sequence of ^ctories that meet the 
specified characteristics. The set of factories against which the FactoiyFinder performs its search is contained in 
the Life Cycle Repository. 

An object may support multiple inter&ces according to its inheritance hierarchy. As dq)icted in FIG. 
29, an inheritance relationship 2900 is shown among various interfaces A-E. An object implementation 2902 is 
supplied for interface E (shaded area). Instances of that implementation support all of the interfaces A-E. The 
problem to be solved then is how to allow a client to locate a factory that produces instances of implementation 
E, v/hsn that client may be using any of interfaces A-E as the criteria for finding that fectory. For example, the 
client may pass the name of inter&ce A to the FactoryFinder and expect to receive one or more ^ctories that 
support that interface. The fectory for implementation E is to be included among those returned. Furthermore, 
the factory for implementation £ is to be returned when the client passes the name of any of the inter&ces A-E 
to the FactoryFinder. 

In accordance with one aspect of the present invention, in order to locate a factory that produces 
instances of an implementation of a particular object (e.g., object E), interface names are registered for the 
factory of implementation E within the Life Cycle Repositoiy. 

One embodiment of the logic associated with registering multiple interfaces for the factory of 
implementation E is described with reference to FIG. 30. Initially, a transaction is begun for performing the 
registrations, STEP 3000. Within the transactional unit of work, the factory for implementation E, in this 
example, is registered under interface Name A, STEP 3002. In particular, the factory object is bound in the 
name space under Name A. 



46 



Additionally, the fiictory for implementation E is registered under intetfece names B, C, D and E. 
STEPS 3004-3010. Tliereafter. the transaction is committed, STEP 3012. (In other examples, there may be 
more or less int«feces. The above is only one example.) 

By using the above procedure, all of the inter&ce names associated with the fectoiy for aparticular 
implementation (e.g., implementation E) are registered in the Life Cycle Rgwsitoiy. This allows a fectoiy that 
produces instances of a particular implementation to be located no matter which interfece is used as the criteria 
for finding the &ctoiy. 

For example, assume that there is a factory that builds employee objects and another factory that buUds 
person objects. Further, assume that a list of all factories that build people is desired, hi accordance with this 
aspect of the present invention, the list includes the employee fectory. since employees are people, as weU as the 
person factory. 

As described above, a server system includes one or more server instances used to manage various 
objects. Further details regarding a server instance is described herein. In particular, in accordance with one 
aspect of the present invention, a server instance is provided that offers integrity (Le. reliabiUty), application 
isolation between privileged and non-privileged applications, enhanced transactiwi recovery time (i.e., 
restart/recovery scalabilily). and effective workload management One embodiment of such a server instance is 
described with reference to FIG. 31. 

In one aspect of the present mvention, a server instance 3 100 includes, for example, one or more 
control regions 3 102 and one or more server regions 3 104. Control region 3102 is an address space (separate 
and apart from the one or more server region address spaces), which executes in privileged mode. It does not 
provide a residence for any user written application code, but does provide various control fimctions, which are 
protected from the appUcations rurming in die one or more server regions. One control fimction provided in the 
control region includes, for example, the processing of security credentials. Most of the state data required to 
map security and transactional context for an inbound request is managed wittiin the control r^ion. 

As one example, control region 3 102 includes an ORB 3 106, which communicates with clients, such as 
a client 3 108; and is coupled to GTS 3 1 10, RRS 3 1 12 and workload manager 3 1 14. 

A server region 3 1 04 is an address space that is used to execute non-privileged appUcation code. It is 
the home for one or more containers 3116; one or more business objects 3 1 18; and one or more data objects 
3 120, which communicate with at least one resource manager 3121. Additionally, server region 3 104 includes 
an ORB 3 122, which communicates vnfh ORB 3 106 of the control region, and is coupled to OTS 3 124. RRS 
3 126 and workload manager 3 128. This is where application processing takes place. A server region can be 
replicated to provide workload balancing. 
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Although ORB 3 1 06 and 3 122 are shown separately, they are logically one ORB, since they are located 
within the same server instance. Similarly, OTS 3 1 10 and OTS 3 124 are logically the same, as well as RRS 
3 1 12 and RRS 3 126; and WLM 3 1 14 and WLM 3 128, 

The separation of privileged and non-privileged functions into separate address spaces within a server 
instance provides integrity and isolation, not provided by the conventional single address space server instance. 
In particular, in a single address space stnicture containing both a runtime component and an execution space for 
business applications, diic levels of integrity and isolation required by enieiprise class applications arc not 
provided. In such an execution space, it is not unusual for errant or misbehaved application code to modify the 
state of the runtime in such a way as to cause either int^ty exposures or feilurc of the server. Examples of 
critical runtime state include shared dispatch queues, security contexts, transactional contexts, workload 
management contexts, and other runtime state required for the management and execution of the application 
server. In the case of handling security contexts, die problem of exposing security related data in the same 
domain in which the application is running, where the possibility of modification of the state data exists, 
represents a significant security exposure in the system. 

Further, typical single process server stnictures allow the scheduling of multiple users executing under 
multiple transactions to be dispatched into die same virtual memory space on multiple threads of execution. 
This approach results in an environment where an application running under one transaction can affect tiie.state 
of an application running under a different transaction, thereby violating die transactional principle of isolation. 

However, in accordance vwdi one aspect of the present invention, a server instance can be configured 
with one of two dispatching policies. The first, allows a given backend server region to accept multiple client 
requests, running in multiple transactional units of work, one on each diread of execution within die 
multi-threaded server region. This policy is referred to as "CICS like", since it most closely represents the type 
of dispatching performed widiin the CICS system. Widi this type of dispatching policy, no transaction 
application to application isolation is provided, since more tiian one transaction may be running within die 
server region address space at the same time. 

The second option for dispatching poUcy restricts the scheduling of work to any given server region so 
tiiat at any given point in time, there is at most one user, running in one transactional unit of work within die 
server region. This policy option is referred to as "IMS like" scheduling. This second option, although more 
consuming of physical address spaces, offers die desired transactional isolation and integrity. 

Anodier flaw with single address space server instances is poor traasaction recovery time. If the 
distributed application server provides die capability of managing work under a transactional unit of recovery, 
tfien die server is also obligated to provide well known recovery actions in die case of failure. One of the pieces 
of recovery after server failure is die re-establishment of die distributed communication channels diat were in 
operation at die time of failure. This recovery action is used to determine whedier or not any further recovery 
action is necessary or desired. In addition, die transaction log which provides information regarding the slate of 
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the transaction in the server at time of failure is read. This log is typically tied to the server address space that * 
failed. This means that each and every address space is to be restarted, replay its transaction log, and then 
detennine whether foither action is required. As the number of server address spaces increase in the system, 
restart time becomes an inhibitor to the efficient and responsive recovery of the system. 

However, in accordance with the server structure of this aspect of the present invention, the recoverable 
resources reside either in backend resource managers such as DB2, or in the control region. There are no 
resources in the server region that need to participate in transactional recovery. This means that the server 
regions do not have to be restarted and participate in recovery after a system failure. Since the recoverable 
object-oriented resources are associated with the control region, only the control region needs to be restarted 
after a failure, significantly improving restart time and scalability. 

In many systems, such as Ae MVS system offered by International Business Machines Corporation, 
(Armonk, NY), workload management decisions witih respect to dispatching priority, memory management, I/O 
priority queue management, eto. are performed at the address space level. The address space is a convenient 
home under which these resources can be managed at the appropriate granularity. If a single address space is 
used to service work under a multiple and diverse set of performance classes, then an undesirable averaging of 
the workload management policies may result, since workload management is making adjustments at the address 
space level for all of the work running in that address space. Thus, in accordance with one aspect of the present 
invention, multiple workload management queues 3 130 are used by woridoad manager 3 114 to balance the 
workload of the server regions. For exan^le, the workload manager may group work with similar performance 
goals on each of the queues and cause the dispatch of that work into a given server region or regions. In 
particular, when a server region is able to accept woric. die ORB of that region pulls a piece of work from its 
respective queue into the region to be processed. 

With the above approach, the workload manager effectively partitions different ckisses of work across 
different physical address spaces, so that the undesirable averaging of performance goal management does not 
occur, as in a single address space system. Further, vnth the above approach, die woikload manager can 
dynamically expand and/or contract the number of server regions based on workload management criteria, such 
as those listed above. 

In the above described implementation of a server instance, if a business object of one of the regions 
wants to communicate with a business object of another server instance, the business object flows an outt>ound 
object request, which proceeds from ORB 3 122 to ORB 3 106 across a link. In one example, the link is based on 
OS/390 cross-memory facilities described in detail in "Enterprise Systems Architecmre/390 Principles of 
Operation," IBM Publication No. SA22-7201-05 {Sept 1998). ORB 3 106 then communicates with the target 
server. 



CLAIMS 

1 . A method of managing a name server of a computing environment, said method comprising: 
creating one or more objects in said name server, and 

managing said one or more objects as transactional objects, wherein said name server is transactional. 

2. The method of claim I , wherein said managing comprises interacting among at least one object of said 
one or more objects and a directory service coupled to said name server within a scope of a transaction. 

3. The method of claim 2, further comprising conununicating among said directoiy service and a resource 
manager coupled to said directory service within said transactional scope. 

4. The method of claim 3, wherein said communicating is via a local backend coupled to said directory 
service and said resource manager. 

5. The method of claim 1 , wherein said creating of an object of said one or more objects comprises: 
beginning a transaction; 

creating a data object and a business object associated with said object under a scope of said 
transaction, wherein said object has a key; 

conunitting said transactional unit of work; and 

creating a directory entry associated with said key. 

6. The method of claim 5, wherein said creating said directory entry is performed as a part of said 
committing of said transaction. 

7. The method of claim 5, wherein said creating said directory entry is performed using a service of a 
directory service, 

8. The method of claim 7, wherein said service is an add service and said directory service is LDAP. 

9. The method of claim 1 , wherein said managing comprises updating an object of said one or more 
objects. 

10. The method of claim 9, wherein said updating comprises: 
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updating one or more attributes of said object wittiin a scope of a transaction; and 

storing said one or more attributes that have been updated in storage associated with a resource 
manager, said storing using a directory service to provide said one or more attributes to said resource manager. 

11. The method of claim 1, wherein said managing comprises deleting an object of said one or more 
objects. 

1 2. The method of claim 1 1 , wherein said deleting comprises: 
deleting said object within a scope of a transaction; and 

deleting data associated with said object from at least one of a directory entry associated with a 
directory service and storage associated with a resource manager. 

13. The method of claim 1 , wherein said managing comprises retrieving an object of said one or more 
objects. 

14. The method of claim 13, wherein said retrieving comprises retrieving data associated with said object, 
wherein said retrieving comprises using a service of a directory service. 

15. The method of claim 14. wherein said service is a search service and said directory service is LDAP. 

1 6. The method of claim 14, wherein said directory service interacts with a resource manager in retrieving 
said data. 

17. A method of manipulating objects within a computing environment, said method comprising: 
creating an object within a server instance of said computing environment; and 
atomically binding said object within another server instance of said computing environment 

18. The method of claim 17, wherein said creating and said binding are performed within a scope of a 
single transaction. 

1 9. The method of claim 17, wherein said atomically binding comprises binding a plurality of objects 
within said another server instance. 

20. The method of claim 17, wherein said creating comprises creating a plurality of objects within said 
server instance. 
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2 1 . The method of claim 17, wherein said another server instance comprises a name server instance. 

22. A method of manipulating objects within a computing environment, said method comprising: 

binding a first object within a name server of said computing environment; and 

binding a second object within said niame sender, wherein said binding of said first object and said 
binding of said second object are performed within a scope of a transaction. 

23. The method of claim 22, further comprising. creating an object within said scope of said transaction. 

24. The mediod of claim 23, wherein the created object is a naming context object and said first object and 
said second object are application objects, and wherein said binding comprises binding said first application 
object under said naming context object and binding said second application object under said naming context 
object. 

25. A method of providing access to an object of a computing environment, said method comprising: 

requesting access, by a requester, to an object located in an address space of said computing 
environment, said requester being resident within said-address space; and 

providing access to said object using a local access proxy located within said address space. 

26. The method of claim 25, wherein use of said local access proxy provides decoupling of one or more 
object references to said object from management of one or more virtual memory copies of said object 

27. The method of claim 25, wherein said requester is one of another object located within said address 
space and an object request broker. 

28. The method of claim 25, wherein said providing access comprises driving a method on said object. 

29. The method of claim 25, fiirther comprising creating said local access proxy. 

30. The method of claim 29, wherein said creating comprises: 
determining a type of said object being requested; and 
obtaining an instance of said local access proxy of said type. 



31. The method of claim 30, wherein said obtaining comprises using a local proxy fectory to provide said 
instance of said local access proxy. 

32 The method of claim 30. further comprising providing a pointer of said instance of said local access 
proxy to said requester, wherein said requester uses said instance of said local access proxy to access said object 

33. The method of claim 25, wherein said providing access comprises using, by said local access proxy, a 
reference to said object to provide access to said object. 

34. The method of claim 25, wherein use of said local access proxy enables said object to be independent 
of any object references owned by said requester. 

35. A system of managing a name server of a computing environment, said system comprising: 
means for creating one or more objects in said name server; and 

J for managing said one or more objects as transactional objects, wherein said name server is 



transactional. 

36. A system of manipulating objects within a computing environment, said system comprising: 
means for creating an object within a server instance of said computing environment; and 

means for atomically binding said object within another server instance of said computing environment 

37. A system of manipulating objects within a computing environmem. said system comprising: 

means for binding a first object within a name server of said computing «ivironment; and 

means for binding a second object within said name server, wherein said binding of said first object and 
said binding of said second object are perforaied within a scope of a single transaction. 

38. A system of providing access to an object of a computing environment, said system comprising: 

means for requesting access, by a requester, to an object located in an address space of said computing 
environment, said requester being resident within said address space; and 



means \ 



; for providing access to said object using a local access proxy located within said address space. 
39. A system of providing access to an object of a computing environment, said system comprising: 
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a requester adapted to request access to an object located in an address space of said computing 
environment, said requester being resident within said address space; and 

a local access proxy located within said address space adapted to provide access to said object 

40. An article of manufecture, comprising: 

at least one computer usable medium having computer readable program code means embodied therein 
for causing the providing of access to an object of a computing environment, the computer readable program 
code means in said article of manufacture comprising: 

compute readable program code means for causing a computer to perform the steps of claim 1 . 

41. An article of manufacture, comprising: 

at least one computer usable medium having computer readable program code means embodied therein 
for causing the managing of a name server of a computing environment, the computer readable program code 
means in said article of manu&cture comprising: 

computer readable program code means for causing a computer to execute the steps of claim 1 . 

42. At least one program storage device readable by a machine, tangibly embodying at least one program 
of instractions executable by the machine to perform a method of manipulating objects within a computing 
environment, said method comprising the steps of claim 17 or claim 22. 
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